• The security features that were identified by the members, supplier and 
distributors in their workshop sessions. These are the characteristics of the portal 
that must be present in order to meet their CTQs. 

• Additional features that were identified in follow-up review sessions with supply 
chain coordinator personnel. These are more subtle features that emerged during 
technical, organizational and authorization discussions. 

• Best practices that are frequently employed in system security and access 
management. 

Each functional component will first be described in terms of purpose and general 
approach. Then details will be provided for each function to specify the capabilities that 
must be present. 

Assuming that the supply chain coordinator desires to use existing 3 rd party software as 
much as possible, the traditional approach of specifying inputs, processing and outputs 
for each function will not be strictly followed here. Rather, the emphasis will be placed 
on clearly describing the full set of capabilities that will be required to deliver the 
features needed to meet the CTQs. The details associated with the specifics of inputs, 
forms, detailed processing and outputs will vary by vendor and the vendor's approach to 
providing the necessary capabilities. It will be the job of the vendors to provide these 
details so that the supply chain coordinator can use them to determine the best approach 
for their requirements. 

Logon (Authentication) 

Function Purpose 

The logon function represents the first line of security and it validates that a user is 
authorized to access the portal. 
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Function Details 

The authentication process begins when a user connects to the portal. At that time they 
5 will be prompted for: 

• Company ID 

• User ID 

• Password 



The user will enter the requested data and it will be encrypted prior to sending it to the 
portal logon function. Additionally the password field will be masked when the user 
enters it (i.e. it won't print on the screen when the user enters it). 



1 5 Once the user has submitted the information, the logon function will check the portal 

access control list to determine if access is permitted to the companylD/userlD/password 



Users failing to enter a valid companylD/userlD/password combination will be notified 
20 of the failure and re-prompted. A userlD will be locked out after n failures. 



The logon function will provide the following password management capabilities: 
• Password disablement after an administrator specified period of inactivity. 



• New user must provide a new password the first time they logon to the portal. 

• Passwords will expire after an administrator specified period of time and the user 
will be required to provide a new one. 
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combination that the user submitted. 
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30 



Alternate passwords will be provided for lost/forgotten password situations. 
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New passwords will be subjected to minimum security password validation rules. These 
will include things like minimum/maximum length, percent of characters that must differ, 
uniqueness, etc. 

Once a user has been successfully authenticated the system will: 

• Offer an option to the user to change their password 

• Show the date and time the user last sign on to the system (detect stolen user ID 
and password). 

• Retrieve the user's profile data that defines what data and functions the user can 
access and transfer to the policy management function (i.e. portal main menu). 

All details associated with the logon session will be written to the audit log. 

The system administrator will be notified of user ID lockout. The following table lists 

User Specified Features. 



Table 9 



Feature 


CTQ 
Category 


Explanation 


Lockout user after n unsuccessful 
logon attempts 


Security, 
Prevention 




Notify administrator of lockouts 


Security, 
Prevention 


This is a proactive notification 
that occurs via email, pager, etc. 
when the attempt occurs 


On line monitoring 


Security, 
Prevention 


This includes administrator 
notification of lockout and 
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Feature 


CTQ 
Category 


Explanation 






could be expanded to include 
other threats or situations. 


Provide alternate passwords for 
lost/forgotten password situations 


Flexibility 




Password expiration; require 
periodic password changes 


Security, 
Prevention 




Acceptable password length 
parameters 


Security 




Ability to assign/select password 


Security 


User can specify their password 
and change it any time. 


Ability to transfer logon 
intelligence. 


Simplicity 


The ability to transfer the user 
profile information that 
specifies what data and 
applications they can access is 
helpful for supporting a single 
sign on capability for the portal. 


Record all activities to the audit 
log 


Security, 

Prevention, 

Reporting 


This was not an explicitly stated 
feature. However, it will be 
required to support the reporting 
features that were requested by 
the users. 



Community Management 



The community management capability allows administrators to manage the user 
activities within the portal. Specifically it provides the capabilities to add, change and 
delete users, and to manage what the user can see and what functions they can perform. 

Community management can be covered in four sections: 
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• Community/Domain Wide Administration 

Describes the supply chain coordinator system wide administrative capabilities 
that will be required to establish the community and the entities that make it up 
5 (i.e. members, suppliers, distributors and supply chain coordinator). 

• Basic Delegated Community Management 

Describes the capabilities that will be needed to achieve the CTQs. Many of the 
capabilities that are found in this basic model can be accommodated by 3 rd party 
1 0 software. Some custom programming will likely be required to manage 

authorization within the complex organizational structures found at the supply 
chain coordinator. 

• Group Hierarchical Management 

1 5 Describes the use of hierarchies to manage access. This will achieve many of the 

simplicity and flexibility related CTQs that were not meet by the basic model. It 
will likely require custom development. 

• Data Publication 

20 Describes a capability that is need to support situations such as joint ownership of 

stores and corporate board committees. It will enable the owner of a group to 
permit user in other groups to access data in the owner's group. This will be 
largely custom development. 

25 Community/Domain Wide Administration 
Function Purpose 
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There are certain capabilities that affect the entire community or all of the occupants of a 
domain (members, suppliers, distributors and supply chain coordinator). These are 
limited to a single system wide administrator and potentially to domain administrators. 

5 Function Details 

Community and domain wide administration will include the following capabilities: 

• Community wide administration 

o Add/change or delete a domain. 
10 o Delegate domain administration to a domain administrator. 

• Domain administration 

Domains are comprised of organizations (e.g. members). Organizations are made 
15 up of data related entities (retailers, distribution center, plants, etc.). The domain 

administrator needs the following capabilities to create and manage organizations 
that make up their domain. 

o Add, change and delete data related entities (e.g. retailers). 
20 o Link data related entities together (e.g. retailers) into an organization (e.g. 

member). 

o Create an organization administrator and delegate the administration of 
their organization to them. 

25 Basic Delegated Community Management 

Function Purpose 

The purpose of community management is to provide a sub administrator with the ability 
30 to control what their users can view and what tasks they can perform. 
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An administrator who has been granted administrative privileges for the sub domain that 
represents their organization performs community management (e.g. a member's retail 
outlets make up the member's sub domain). 

The basic model provides the administrator with tools that are used to manage a user's 
access (view and tasks). These tools include: 

o Groups to specify span of control. 

o Privileges to specify tasks. 

o Roles to specify a set of privileges that are associated with a function (e.g. retail 
outlet manager). 

Community management then provides the administrator with the ability to add, change 
and delete users. 

Lastly it enables the administrator to control user's view and access rights by associating 
them with a group of data related entities (e.g. retailer) to specify what the user can see 
and with a role or specific privileges to specify what tasks the user can perform. 

Figure 74 is a flow diagram showing how group and roles manage access. User ABC 
7402 is associated with Group 2 and is assign a manager role. This entitles ABC to order 
F and P and view forecasts for retail outlets 1 and 2. 

Function Details 

Functional details will be covered in the context of groups, roles and users. 
Group Management 
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As stated earlier, a group is an organizational entity that is made up of one or more data 
related entities. The retail outlets owned by a franchisee comprise a member group. 
Groups serve to specify a user's span of control when they are associated with a user. 

An administrator who has been authorized to manage groups can create new groups, and 
change and delete existing groups. 

New groups: 

• Requires an ID that is unique in the administrator's span of control. 

• Requires a descriptive name. 

• Entities (e.g. retailers) that are placed in the new group must exist within the 
administrator's span of control. 

In order to change or delete a group, it must exist in the administrator's span of control. 
Entities being added to an existing group (change) must exist in the administrators span 
of control. 

Role Management 

A role is a functional entity that is made up of tasks the function is permitted to perform. 
A restaurant manager is a role that is permitted (i.e. given a privilege) to perform the 
tasks of ordering food and packaging, and viewing forecasts. 

An administrator who has been authorized to manage roles can create new roles, and 
change and delete existing ones. 

An administrator must possess any privilege they assign to a role. 
New roles: 

• Requires an ID that is unique in the administrators span of control. 
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• Requires a descriptive name 

In order to change or delete a role, it must exist in the administrator's span of control. 

Privileges can be specified as default or optional when they are assigned to a role. Default 
privileges are automatically given to a user when they are assigned to a role. The 
administrator must explicitly specify each optional privilege (yes/no) for a user when 
they are assigned a role. 

A role may be assigned to a group as well as to a user. When it is associated with a group, 
users receive the privileges specified by the role when they are associated with the group. 

User Management 

A user is an individual who is authorized to perform some set of tasks on behalf of a 
group (e.g. a set of retail outlets). 

An administrator who has been authorized to manage users can create new users, and 
change and delete existing ones. 

A company ED, a user ID and a password identify a user. The administrator cannot view 
the user password. 

New users: 

• Require a user ID that is unique in the sub domain (e.g. unique within a member 
organization). 

• Require an email address. 

• Require a descriptive information such as name and address name. 

• The system will assign the password to a new user and inform them of it via 
email. 
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User span of control: 

• The administrator specifies a user's span of control by associating the user with a 
group(s) that represent the desired span of control. 

• The administrator can associate (add) and disassociate (remove) users with 
groups. 

• In order modify a user's span of control, the user must exist within the 
administrator's span of control 

• In order associate a user with a group, the group must exist within the 
administrator's span of control. 

User/group application access: 

• The administrator specifies the application a user/group can perform by assigning 
roles/privileges to the user/group. 

• The administrator can add and remove roles/privileges from users/ groups. 

• In order assign a role to a user/group, the role must exist within the 
administrator's span of control. 

• In order modify a user roles/privileges, the user must exist within the 
administrator's span of control. 

• An administrator must possess any privilege they assign to a user/group. 

• If a role is being assigned to a user/group, and if the role has optional privileges, 
the administrator will be shown the optional privileges and allowed to remove 
ones that they don't want to grant to the user. 

Other 

All details associated with community management activities will be written to the audit 
log. 
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A capability to link community management with the supply chain coordinator's member 
management system is required to eliminate duplicate data entry and keep the two 
systems synchronized. 

A batch bulk load capability is required to enable user to export data from existing 
systems to set up their organization in the portal community. 



Table 10 



Feature 


CTQ 
Category 


Explanation 


Distributed community 
administration 


Flexibility 


Users need to be able to manage 
their users and their access 
within the portal. They don't 
want to be dependent on the 
supply chain coordinator. 


Ability to add, change and 
delete users. 


Security, 
Flexibility 




Ability to assign access to users 


Security, 
Flexibility 


Specify span of control and 
privileges 


Ability to create roles or level 
of users 


Simplicity, 
Flexibility 




Ability to set up default levels 
of access 


Simplicity, 
Flexibility 




Ability to clone and/or access 
rights 


Simplicity, 
Flexibility 




Mass delete of users 


Simplicity, 
Flexibility 


Not provided as a part of 
community management. 
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Ability to copy a user ID 


Simplicity, 
Flexibility 


Provide to extent that a user's 
access attributes can be easily 
specified through groups and 
roles 


Ability to export user load 
information from member 
backend. 


Cost 


Large member would like to use 
existing data to 
establish/maintain their 
organization in the portal. 


User can be associated with 
multiple groups. 


Flexibility 


District manager A is a backup 
for district manager B. As a 
result, A will need to perform 
ordering district A and B and 
will need to be associated with 
both groups. 

Feature will also be required to 
support organizations such as 
finance who will need to view 
the data of several groups. 



Hierarchy 
Function Purpose 

The basic community model that was outlined in the previous section supported 
authorization and access management for a flat single level organization. Although this 
can be adapted to support a multi-level organization, it falls short on the CTQs related to 
simplicity and flexibility. Specifically, the administrator must create groups to correspond 
to each span of control. This results in a single entity having to be included in several 
groups. For example, a single retailer may be included in a district, region and a corporate 
group. Administration in a scenario like this is complex and labor intensive. It becomes 
particularly cumbersome and error prone because things like an organization change (e.g. 
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new retail outlet) requires the modification of several groups (i.e. add it to district, region 
and corporate group). 

A hierarchy provides a superior way to manage span of control and access. The hierarchy 
5 defines a company's organization. A user's span of control is set by associating them to 
the node of the hierarchy that corresponds to their position in the company. This 
association authorizes them to view the data associated with any entity that belong to the 
node to which they are assigned. In the case of a new retail outlet, assigning it to a 
manager also places it in the span of control of the manager's district and region mangers 
1 0 and the corporate CEO. 

Hierarchies can also simplify the specification of user privileges by associating them to a 
hierarchy. 

1 5 Although hierarchies introduce technical complexity, they greatly simplify administration 
in large and complex organizations. 

The following outlines the requirement details associated with hierarchies. 
20 Function Details 

A hierarchy is made up of nodes where a node represents a business function (e.g. retail 
outlet manager, district manager, etc.). The bottom nodes of a hierarchy are associated 
with a data related entity (e.g. retail outlet is associated with a manager node/function). 
25 They are then grouped under nodes at successively higher levels (e.g. districts, regions, 
etc.). The top of the hierarchy is a single node (e.g. corporate). In a hierarchy an entity 
(e.g. retail outlet) will appear in the span of control of each successive parent node. 

The following administrative capabilities are required to manage authorization and access 
30 with hierarchies. 
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Hierarchy Management 

• Add a node 

Specify a parent node in a hierarchy and add a node beneath it. 

• Delete a node 

Specify a node in a hierarchy and delete it. This also results in the deletion of any 
dependent nodes reporting to the node that was deleted. 

• Move a node 

Specify a node in a hierarchy and move it and its dependents to another node 
(drag and drop). 

• Associate a data entity with a node 

Specify a node in a hierarchy and associate a data related entity to it (e.g. retailer) 
with it. In this situation, no nodes can exist beneath the node specified. Also the 
data related entity must exist in the administrator's span of control. 

• Disassociate a data entity with a node 

Specify a data related entity in a hierarchy structure and delete it from it parent 
node. 

• Move a data entity from one node to another 

Specify a data related entity in a hierarchy structure and move it from its present 
parent node to a new parent node (drag and drop). 

User Span of Control Management 

Span of control relates to the data a user can view. Under a hierarchy, associating a user 
to a node in a hierarchy specifies their span of control. This association entitles the user 
to view the data associated with any entity that is found in the user's node group. 

User Access Management 
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Access management relates to the functions a user can perform. It is controlled by 
privileges and roles that are assigned to a user (groups of privileges). Under a hierarchy, 
roles and privileges can be associated to a node. Any user who is then associated to the 
node receives the privileges that accompany it. See the table below. 



Table 11 



Feature 


CTQ 
Category 


Explanation 


Ability to publish rights and 
privileges across hierarchies. 


Simplicity, 
Flexibility 




Ability to authorize multiple 
levels of a hierarchy 


Simplicity, 
Flexibility 




Ability to manage access 
against hierarchies 


Simplicity, 
Flexibility 




Flexible data access and 
management. 


Simplicity, 
Flexibility 





Data Publication 
Function Purpose 

Portal data (e.g. a retailer) is owned by one and only one sub domain entity (e.g. 
member). The ability to view and process that data is restricted to users and groups who 
inhabit the entity's sub domain and who have been authorized to do so by its 
administrator. 

However, there are several business situations where an organization needs to view and 
process data that is owned by another organization that may or may not belong to the 
same domain. Some common examples are: 
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• Two members share ownership of a retailer. As a result both members need to 
view information about the jointly held retail outlets and order supplies for them. 

• Members belong to the supply chain coordinator board or corporate committees. 
5 In order to participate in these roles the members need to view and potentially 

access data in the supply chain coordinator's domain. 

The data publication capability is a mechanism for the owners (e.g. member A) of an 
entity (e.g. retailer 123) to permit a users in another organization (e.g. member B) to view 
10 and access the entity's (i.e. retailer 123) data. 

Function Details 

Data publication is an administrative privilege. It is used by a data owner's administrator 
1 5 to setup a relationship with another party in the portal that will allow that party to view 
and access data entities (e.g. retailers) that are found the owner's sub domain. 

The data publication function will possess the following capabilities. 

20 • The administrator can add, change or delete a data publication relationship. 

• Any data entity that is published must exist in the administrator span of control. 

• The following elements will be provided to specify a data publication 
25 relationship. 

o The span of control (view) that is associated with a data publication. The 
span of control may be specified as an individual entity (e.g. a retailer), a 
group (e.g. a district) or a hierarchical node (if a hierarchy feature is 
30 provided). 
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o Privileges or functions the receiver can perform with the published data. 

o The domain (i.e. member, supplier, distributor, supply chain coordinator) 
and sub-domain ID (company ID) of the organization to which the data is 
being published. 

o The group or node ID in the receiving organization that the published data 
will be associated with. 

o The user ED of the person in the receiving organization who will own the 
data. This person will control the user views and access (privileges) 
associated with the published data in their organization. 

• All details associated with creating or modifying a data publication relationship 
will be written to the audit log. 

The following table sets forth User Specified Features: 



Table 12 



Feature 


CTQ 
Category 


Explanation 


User can view or access data in 
another sub-domain in their 
domain. 


Simplicity 
Flexibility 


Joint ownership of retail outlets by 
distinct members. 


User can view or access data in 
different domain. 


Simplicity 
Flexibility 


Support board of directors and 
committees that require members 
to view and access supply chain 
coordinator corporate data. 



Policy Enforcement 
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Function Purpose 

The policy enforcement function is a centralized capability that manages access to all of 
5 the applications that comprise the portal. 

Policies specify the access requirements for each application that makes up the portal. 
The policy enforcement function determines if a requesting user meets the access 
requirements for an application. The user is granted access by the policy enforcement 
1 0 function if they meet they requirements specified by the policy. 

Function Details 



A central administrative capability is required to maintain the policies that are used to 
1 5 manage access to the portal's applications. 



• When a user successfully logs on to the system by providing a valid user ID and 



The details associated with policy enforcement are as follows: 



20 



password, their span of control and application privileges are retrieved. 



• The user is presented with main menu for the portal. 



• The user requests a function from the menu. 



25 



• The policy enforcement function retrieves the access policies for the requested 
application from the central policy repository. 



30 



• The user's span of control and application privileges are evaluated against the 
application's policies. 
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• If the user satisfies the requirements specified by the policy, access is granted. 

• If the user does not satisfy the requirements specified by the policy, access is 
denied. 

• Details associated with an access request are recorded in the central audit log. 

• The policy enforcement function is responsible for interfacing with the portal 
applications and passing them information about the user that they require. 

The following table sets forth User Specified Features. 



Table 13 



Feature 


CTQ 
Category 


Explanation 


Single sign on 


Simplicity 


After signing on to the portal, 
the user can access all 
applications that make up the 
portal. 


Ability to integrate with 
affiliates (i.e. other 3 rd 
applications that make up the 
portal). 


Simplicity 
Integration 
Cost 


Provide the affiliate application 
with the user information it 
requires to function. Prevent 
redundant data entry, redundant 
security, etc. 


Ability to interface with other 

applications: 

supply chain coordinator 

3 rd party 

Remote hosts 


Simplicity 
Integration 
Cost 


The supply chain coordinator 
wants to use 3 rd parties and 
application service providers 
(ASPs) for their portal 
applications. The policy 
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Feature 


CTQ 
Category 


Explanation 


Platform independent 




enforcement manager must be 
capable of interfacing with a 
variety of platforms in a variety 
of situations. 


Centralized policy management 


Simplicity 
Integration 
Cost 


Don't want redundant 
application access permission 
management. 



Reporting 
Function Purpose 

The portal must provide its administrators with two forms of reporting: 

• Community management reports. 

• An event reporting capabilities that provides the administrator with the data and 
tools for researching issues, problems, potential breaches, etc. 

Functional Details 

The functional details of reporting will be covered from the perspective of report type. 
Community Management Reports 

Community management reports provide administrators with the information they need 
to manage their users, groups, roles and hierarchies (if implemented). 

Reports will likely include: 

• User information report showing things such as: 
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o Basic user information (name, address, telephone number, etc.) 
o User span of control 
o Roles/privileges 

o Usage data (date of last logon, number of logons, total logon time, average 

logon time, etc.) 
o User lockout 

• Group reports showing thing such as: 

o The entities (e.g. retailers) that make up a group, 
o Role associated with a group, 
o Users associated with a group. 

• Role reports showing things such as: 

o Default and optional privileges associated with each role. 

o Groups associated with each role. 

o Users assigned to each role. 

o Users assigned to each available privilege. 

Report content will be limited by the administrator's span of control. 

Query and filter capabilities will be required to specify report type and content (e.g. a 
specific group, a range of users, all roles, user usage details for date range, etc.). 

Event Reporting 

An event is a system activity that is written to the audit log. Examples of events include 
connection to the portal, logon attempt, application access requests, add a new user, 
system errors, etc. Information will accompany an events that identifies it, identifies the 
user that initiated it, the date and time the event was initiated, status (success/failure), etc. 
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Events are recorded so that the details associated with them are available to research 
problems, security breach attempts, etc. 

An alert capability is required to specify administrator notification (email, page, etc.) in 
the case of certain events (e.g. attempted breach, a portal application is unavailable, etc.). 

Because event reports from the audit log are run in response to problems or issues, good 
filtering capabilities will be required to eliminate unneeded data and provide the 
administrator with only the information they are seeking. Filters should include user(s), 
event, and date and time. 

The following table sets forth User Specified Features. 



Table 14 



Feature 


CTQ 
Category 


Explanation 


The following community 
management reports were 
identified: 
Master user list 
Click and view access list 
User with published data 
authorization (i.e. users in other 
domains or sub-domains. 
Usage reports 


Security 

Reporting 

Prevention 




Lockout notification 


Security 




Online monitoring capability 


Security 

Reporting 

Prevention 




View audit log 


Security 
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Feature 


CTQ 
Category 


Explanation 




Reporting 
Prevention 




Parameter driven reports 


Simplicity 
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Technology 

5 Component and Actor definition of the supply chain coordinator web portal 

As detailed in the previous section, the supply chain coordinator's portal may allow 
access to supply chain applications. The nature of the applications require a feature and 
function set; this engagement collected CTQs and functions from the community and 
10 organized them along categories. 

This section places a slightly different view of requirements on the portal. There may be 
a public site and a private site (secured access); there may also be applications behind the 
portal provided by 3 rd party application service providers that fall under the private site. 
1 5 There may be administration pages to setup authentication and authorization policies. It 
is also a requirement that the portal support communications between the supply chain 
coordinator and the community and between community members. 
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System View Components 



Some functional components that may comprise the Portal: 



• PVC: Public View Component 

• SVC: Secure View Component 
25 • AC: Administrative Component 

• CUC: Contact Us Component 
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A more detailed description of each of these components is stated in the following 
sections. 

5 Public View Component 

The Public View Component describes the functionality that is available to users of the 
public web pages on the supply chain coordinator portal 

10 Secure View Component 

The Secure View Component describes the functionality that is available to users once 
they have logged onto the private pages of the supply chain coordinator portal. The 
private pages include access to the Applications and other functionality. 

15 

Administrative Component 

The Administrative Component describes the functionality that allows users to access 
administrative links available to Company Administrators and individual Users. 
20 Additionally, the component contains information required for users to log on and request 
passwords. 

Contact Us Component 

25 The Contact Us Component describes the functionality and information that is available 
to users on both the public and private pages of the supply chain coordinator. This 
information consists of service-related questions and other areas of concern for 
community members. 

30 Actor Definition 
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An actor is a user that plays a role with respect to the system. It is someone or something 
outside the application that interacts with the supply chain coordinator portal. The 
defined use cases and their definitions are specified below. 

5 The systems 'Actors' are the different types of people involved in the business process. 
Earlier, several types of users are defined for each customer type (supply chain 
coordinator member, supply chain coordinator, supplier, distributor, retail outlet 
manager). While those are separate organizations, the actors in each share qualities at 
this high level of definition. The actors for the supply chain coordinator exchange portal 

Company Administrator (Tier 1 Registered User; Access to public and private 
pages) 

Exchange User (Tier 2 Registered User; Access to public and private pages) 
Non-Registered User (Tier 3; Access to public pages only) 
Content Manager (CM, Internal GXS/RM User who has permissions to submit 
updated content; Access to public and private pages) 
Internal Administrator (Internal GXS/RM User who has permissions to run 
reports validate the registration status of potential customers; Access to public and 
private pages) 

Actor Details 

Company Administrator; (Tier 1 Registered User; Access to public and private pages) 

25 

Description: A Registered User (Tier 1) is a registered community member who has 
Company Administrator responsibilities for their account. 

Computer skills: Computer skill can vary, but a general knowledge of the Web is 
30 assumed. 
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Business Knowledge: Knowledge of products and services related to the supply chain 
coordinator suite of applications. This User may be responsible for setting up 
roles/responsibilities/permissions for Tier 2 Users in the account and company. 
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5 Exchange Level User; (Tier 2 Registered User; Access to public and private pages) 

Description: A Registered User (Tier 2) is a registered user who has the second level of 
privileges. Tier 2 Users may use applications for which they are registered, but they may 
not sign up for additional applications without approval from their Tier 1 User. 
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Computer Skills: Computer skill can vary, but a general knowledge of the Web is 
assumed. 

Business Knowledge: Knowledge of products and services related to a solutions suite of 
applications. 



Non-Registered User; (Tier 3; Access to public pages only) 



Description: A Non-Registered User (Tier 3) has access to the public pages of the 
supply chain coordinator. They may be able to register via their company administrator, 
(if the company has registered) or they may be able to register via the automated 
registration process (an option described in the upcoming sections). Until they are 
25 registered, Tier 3 users may not have any level of access to the private pages of the 
supply chain coordinator. 

- Computer Skills: Computer skill can vary, but a general knowledge of the Web is 
assumed. 

30 Business Knowledge: Knowledge of products and services related to the solutions suite 
of applications. 
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Content Manager 

Description: A CM is a Content Manager who has been authorized to add/update content 
5 to the portal, pertaining to the particular products they own. 

Computer skills: Computer skill can vary, but a general knowledge of the Web is 
assumed. 

Business Knowledge: Knowledge of products and services related to the solutions suite 
10 of applications. 

Internal Administrator 

Description : An Internal Administrator is a registered user who has been authorized to 
1 5 access certain report generation functionality on the private pages of the supply chain 
coordinator. They may be the only users allowed to view certain links related to report 
generation (Similar to Content Managers and the Upload Content Link). 

Computer skills: Computer skill can vary, but a general knowledge of the Web is 
20 assumed. 

Business Knowledge: Should be at the RailMarketplace.com, Inc. or GXS executive or 
marketing level, interested in site usage and feedback for further enhancements. 

Portal Components and Requirement Index 

25 

The following section is an attempt to outline the requirements expressed by 
stakeholders/subject matter experts (SMEs) associated with the supply chain coordinator 
portal. These requirements revolve around the feature/function lists collected in meetings 
with the supply chain community as addressed in the previous sections. This list should 
30 be considered proposed at this point and based on GE's interpretation of the features 
collected. IT may be finalized through prioritization and solution decisions. It may be 
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further refined by the design process that the organization chosen to deliver this solution 
must complete during implementation. 

A listing of these component areas along with their index key is provided below. Table 
5 1 5 provides a listing of functional requirements so that they can be easily found. 

Index Key 

PVC: Public View Component 
10 SVC: Secure View Component 
AC: Administrative Component 
. h CUC : Contact Us Component 

3 Table 15 



Req. ID 


Requirement Name 


Included in 
Approach 


Public View Component 


UC-PVC.01 


View Public Site 




UC-PVC.02 


View supply chain coordinator press releases 




UC-PVC.03 


View Service Info 




UC-PVC.04 


View Media Coverage/Latest News 




UC-PVC.05 


Request to Register 




UC-PVC.06 


View Legal Pages (Extends from PVC.06) 




UC-PVC.07 


View About Us 




UC-PVC.08 


View Site Map 




UC-PVC.09 


View FAQ's 




UC-PVC.10 


Submit Feedback 




Secure View Component 


UC-SVC.01 


View Secure Welcome Page 
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UC-SVC.02 ! 


Select Application 




UC-SVC.03 


Launch Application 




UC-SVC.04 ' 


View Application Request Form 




UC-SVC.05 


Submit Application Request Form 




UC-SVC.07 


View "Community Directory" 




UC-SVC.08 


Search "Community Directory" 




UC-SVC.09 


Community Directory- New User Listing 




UC-SVC.10 


Submit Feedback 




UC-SVC.ll 


Submit User Survey 




UC-SVC.12 


Register for Training 




UC-SVC.13 


Quit Private Pages 




UC-SVC.14 


View Press Releases 




UC-SVC.15 


View Service Info 




UC-SVC.16 


View Media Coverage/Latest News 




UC-SVC.17 


View Site Map 




UC-SVC.18 


View FAQ's 




Administrative Component 


UC-AC.01 


Login 




UC-AC.02 


Submit "Password" Reminder Request 




UC-AC.03 


Re-set Password 




UC-AC.04 


Submit "Administration" Change Request 




UC-AC.05 


Add Content 




UC-AC.06 


Submit "User Information" Change Request 




UC-AC.07 


Generate User Report 




UC-AC.08 


Generate Site Activity Report 




UC-AC.09 


Clone User 




UC-AC.IO 


Mass Delete of Users 




UC-AC.ll 


Create and Manage Hierarchies 




UC-AC.12 


Manages Access Rights Relative to Hierarchies 




UC-AC.13 


Grant Privilege to Another User 
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UC-AC.14 


View Master User List 




UC-AC.15 


View Access List 




UC-AC.16 


View Users Who Can Access My Company's Data 




Contact Support Component 


UC-CUC.01 


Submit Tech Support Feedback 




UC-CUC.02 


View Tech Support Main Page 




UC-CUC02 


Access Email ASP 




UC-CUC.04 


Submit Press Analyst Questions 




UC-CUC.05 


View Business Development 




UC-CUC.06 


Submit Billing Questions 




UC-CUC.07 


Submit Accounts Payable Questions 




UC-CUC.08 


Verify Account Information 




UC-CUC.09 


Submit "Other" Questions 





m 

i y Technology Options 

i J 5 Now that the features have been defined and categorized, and the portal components and 

VII 

5 ;1 actors are known, technology must be selected to address high priority items such as 

C!1 integrating affiliate sites, central policy management, and distributed user administration. 
Considerations for this selection may include the following IT strategy drivers: 



10 Integrating existing and new security systems 



• Integrating existing applications with new Web-based applications 

• Providing a seamless integration between portal and affiliate sites 

• Delegated and single-point administration 
15 • Centralized security management 

• Scalability of the integrated security systems 
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This list of general drivers matches up well to the feature list as collected: 

• Distributed User Administration 

• Administrative Audit Trail 

• Access Management 

• Logon/Password Management 

• Reporting 

• Policy Enforcement 

• Data Management 

Security is a major concern, as web sites may contain proprietary business information 
such as news, data/information, and procurement systems. Without adequate security, 
opportunities are presented for inappropriate dissemination of proprietary information, 
sabotage, and other mischievous acts. 

Comprehensive Security for the supply chain community breaks down into three areas: 
Web, Network, and Security. Each of the features extends across all three areas, as the 
following chart illustrates. 



Figure 75 is a schematic illustrating features 7502 and functions 7504 across web 7506, 
network 7508 and system areas 7510. Each area is very important to a strong security 
policy that may allow the supply chain coordinator to operate in a real-time integrated 
supply chain mode, but community management at the web layer was the main focus of 
25 this engagement and where most of the options and decisions need to be made. 

Technically, from the web portal view, there are two main approaches to meeting the 
CTQs of the supply chain communities. The first option is for the supply chain 
coordinator to use its existing NT infrastructure. The second option involves purchasing 
30 a portal management solution to abstract user management from applications. 
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• Using the existing NT infrastructure 

• Using the basic functionality of the portal management solution with minimal 
configuration 

If option 2 is selected, there are two additional levels of implementation that are additive 
to option 2. These may be overall options 3 and 4: 

3. Further development within the portal management solution to add additional 
features 

4. In addition to extension of the portal management solution, creating custom 
developed community administration features in a relational database that are 
matched to the portal directory structure 

There is a choice to be made between approach 1 and 2. Approaches 2 through 4 build 
on each other, with approach 4 including all the functionality of choices 2 and 3 as well. 
Within choice 2, 3, and 4, there are also sub-decisions to make about products or level of 
customization. Table 16 illustrates chart comparing options and product/customization 
levels. 



Table 16 



Option 1 


Option 2 


Option 3 


Option 4 


Use current NT 


Netegrity or 


Security 


Security 


security solution 


Securant Security 


Management 


Management 




Management 


Solution Software + 


Solution Software + 




Solution Software 


Custom 


Custom 






Administration 


Administration + 








Advanced 








Community 
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Structure 



The technology portion of this report may provide a section on each approach. The 
technical architecture for each may be detailed, as well as decisions that can be made by 
the supply chain coordinator within each. Each section may then compare the 
5 functionality pieces outlined in the section entitled Fundamental Requirements to that 
provided by the approach being described. Finally, costs and level of effort for each 
approach may be included at the end of each section. 



After each web portal approach is documented, sections on network and application 
10 development recommendations may also be included. 

Option 1: Using Internal NT Security 
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Solution Overview 



The supply chain coordinator already manages Windows NT user accounts for all the 
employees of the supply chain coordinator. This is to control access to internal business 
applications. The IT team has the ability to create and delete users, assign user groups, 
and assign privileges to either the individual user or the user group. Access Control Lists 
20 manage the resources each user or user group can access, as well as the level of access 
such as Read, Write, or Execute. These are some of the same functional requirements for 
the integrated supply chain portal. 



Moving to Internet based systems in the NT environment, most applications developed 
25 using Microsoft languages and methods run with Microsoft IIS as the webserver. IIS has 
authentication functionality included. IIS also provides a authorization features as well 
such as Read and Write, and since IIS runs as a service on top of Windows NT, it relies 
heavily on Windows NT user accounts and the Windows NT File System. 
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This is the approach the supply chain coordinator uses for the pilot web portal system. 
The supply chain coordinator has created an NT domain for the web application to use. 
The supply chain coordinator is setting up user accounts in this domain, and the web 
application is validating users against Windows NT. 

5 

Figure 76 is a schematic diagram 7600 showing a current validation of users on a web 
portal 

For data access in the current web portal, there is an association of retailers to specific 
10 supplier, distributors, or supply chain members. This resides in a supply chain SQL 
database 7602. The application itself logs onto the database and queries the requested 
information, using the user id 7604 as a key to make sure the proper data is retrieved for 



15 There are ways that the supply chain coordinator could continue this operation to manage 
the entire community of supply chain users. This would involve centrally administering 
users and physically adding them to the NT user base. The supply chain coordinator 



would own validating users and setting up access rights, and would need to communicate 
frequently with companies (supply chain members, suppliers, distributors) to make sure 



In order to integrate 3 party provided applications, custom integration would be required 
in the link between the supply chain portal and the ASP application. The supply chain 
could work a transfer of user information in the http headers of linked websites. This 

25 would provide for an authentication of the user on the 3 rd party site. After the initial 

transfer, the user would interact with the 3 rd party application directly with zero visibility 
back to the portal. Each 3 rd party application would also need to manage users 
themselves and make sure that their user directories were synchronized with the supply 
chain coordinator, A way around this is for the third party application to trust that the 

30 user being passed is valid and to pass all application-specific data to the application at the 



presentation back to the user. 



20 



that user setup was proper. 
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time of the link. This provides an easier administration in this model but a much lower 
level of security and is not recommended. 

Reporting would be handled by the IIS logs. If community members wanted to know 
what their employees were doing on the supply chain applications, they would need to 
submit a request to the supply chain coordinator. The supply chain coordinator would 
then need to manually check their logs and find out what user activities occurred. If a 
community member wanted to know what activities were performed on a 3 rd party hosted 
application, the supply chain coordinator would then need to contact the 3 rd party 
provider and have them manually search their logs and provide reports back to the supply 
chain coordinator which could then be shared with the community member. 

Comparison to Requested Functions 

In a previous section, the features requested by the supply chain community were detailed 
along with the functions those features imply. The following table shows whether 
functions are provided by this approach along with an explanation. Table 17 illustrates 
features within option one. 



Table 17 



Feature 


Y/N 


Explanation 


SECURITY 






Lockout user after n unsuccessful 
logon attempts 


Y 


Application can be written to lockout 
after n successful tries 


Notify administrator of lockouts 


Y 


IIS log should capture failed attempt. 
Application can capture lockout event 
and write to NT log 


On line monitoring 




Lockouts are captured in the NT log. 


Provide alternate passwords for 
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Feature 


Y/N 


Explanation 


lost/forgotten password situations 






Password expiration; require 
periodic password changes 


Y 


This can be configured in NT and 
added to application with minimal 
development 


Acceptable password length 
parameters 


Y 


Included in NT 


Ability to assign/select password 


Y 


The supply chain coordinator would 
create in IIS 


Ability to transfer logon 
intelligence. 


N 


Not part of NT; a custom integration 
effort is required per additional 3 rd 
party application. 


Record all activities to the audit 
log 


N 


Only activities for applications the 
supply chain coordinator hosts can be 
captured. 


COMMUNITY 
MANAGEMENT 






Distributed community 
administration 


N 


The supply chain coordinator must 
manage the community centrally 


Ability to add, change and delete 
users. 


Y 


The supply chain coordinator would 
perform centrally 


Ability to assign access to users 


Y 


Access Control Lists could be setup in 
NT 


Ability to create roles or level of 
users 


Y 


NT allows user groups. Levels 
beyond that are not supported. 


Ability to set up default levels of 
access 


Y 


Read or Write 


Ability to clone and/or access 
rights 


Y 


NT can be configured to allow this. 
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Feature 


Y/N 


Explanation 


Mass delete of users 






Ability to copy a user ID 


Y 


There are workaround to enable this 
using NT. 


Ability to export user load 
information from member 
backend. 


N 


Details would be needed and sent to 
the supply chain coordinator for a 
custom load 


User can be associated with 
multiple groups. 


N 


Here groups refers to corporate 
organizations, and NT structure makes 
all users part of the same organization 
within an NT domain. 


Hierarchies 


N 


NT security does not support complex 
hierarchical structures. 


Ability to publish rights and 
privileges across hierarchies. 


N 


No hierarchies. 


Ability to authorize multiple 
levels of a hierarchy 


N 


No hierarchies 


Ability to manage access against 
hierarchies 


N 


No hierarchies 


Flexible data access and 
management. 


N 


NT provides very rigid security 
structures 


DATA PUBLICATION 






User can view or access data in 
another sub-group in their 
domain. 


N 


Data is within a domain. 


User can view or access data in 
different domain. 


N 


NT has single domain. 


POLICY ENFORCEMENT 






Single sign on 


N 


A workaround for SSO is detailed in 
the section above, but IIS and NT are 
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Feature 


Y/N 


Explanation 






not SSO products. 


Ability to integrate with affiliates 
(i.e. other 3 rd applications that 
make up the portal). 


N 


Not supported. 


Ability to interface with other 
applications: 

the supply chain coordinator 
3 rd party 
Remote hosts 
Platform independent 


N 


Not supported 


Centralized policy management 


N 


This refers to all policies for multiple 
applications. NT security manages 
policies for all applications running on 
in the NT domain, but not applications 
outside of it. 


REPORTING 






The following community 
management reports were 
identified: 
Master user list 
Click and view access list 
User with published data 
authorization (i.e. users in other 
domains or sub-domains. 
Usage reports 




The NT admin can view some of these 
reports, but they would not be 
available to the general community as 
this requirement specifies. 


Lockout notification 


Y 


NT admin can see lockout notification. 


Online monitoring capability 


N 


Not available through web. Available 
to NT admin on admin desktop. 


View audit log 


Y 


Admin can view 
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Feature 


Y/N 


Explanation 


Parameter driven reports 


N 


Not provided to community users. 



It is possible to custom develop additional authentication and access control functionality 
on top of NT-based applications. Code can be written in ASP to provide this additional 
functionality, which would provide a portion of the functionality included in the products 
considered for option 2. For the purpose of this study, however, it is assumed that the 
cost of such development would greater than the cost of option 2, purchasing a portal 
management solution. 

Costs and Timelines for Option 1 

In terms of up front cost, this is the supply chain coordinator's lowest cost alternative. 
The NT administration features already exist, the supply chain coordinator has skilled NT 
administrators, and the equipment is already in place. An additional server may be 
required to handle the number of portal requests once the applications are fully available 
and ramped. 

However, this approach fails on several fronts including application integration and 
distributed administration. Therefore, the supply chain coordinator would need to 
manage the community centrally with this alternative. The supply chain coordinator 
would need many administrators to manage the community with this approach, so that 
should factor into the ongoing costs of this approach. 

Option 2: Implementing a Portal Management Solution 

Two shortfalls of using the internal NT approach are: 

• The supply chain coordinator would only be able to have one set of business rules 
apply to each user 
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• Users would need to be managed centrally. 

These shortfalls are especially critical considering the supply chain coordinator is 
planning to outsource many of the applications behind the portal to ASP providers. In a 
5 sense, the supply chain coordinator may become an ASP integrator. With this in mind, a 
component of a solution is providing a clear method for the supply chain coordinator to 
deliver ASP model services to members and trading partners with distributed 
administration. 

1 0 Extracting User Management From Applications 

Option 2 is based on a layer of abstraction between security and the supply chain 
coordinator's applications. Doing this entails purchasing a security management solution 
that offers single sign-on and the ability to create a unified directory for users across 

1 5 applications. The benefit of the unified directory is the ability to enable the same user to 
belong to multiple applications (managed by different community owners) without the 
need to manage the user as many separate users. For example, the supply chain member 
could belong to the supply chain board community to access board-related reports. The 
same user may be a user of a supply chain service application, such as order 

20 management. In addition, the supply chain member may be enabled to access 

collaborative applications such as email. The issue, however, is that each application has 
its own set of privileges and roles that drive business process. 

In a single-entity model, such as option 1, roles are defined and users are assigned 
25 privileges and roles. However, the defined privileges and roles are pervasive across all 
applications that are accessed by that sign-on. Allowing the same user to have a single 
sign-on with different roles based upon the application community they are interacting 
with (even the same physical application in two different communities) is not possible. 
This is possible if the supply chain coordinator chooses to implement a single sign-on 
30 infrastructure including a unified directory environment, as the community is separate 
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from the directory that defines the users. Figure 77 graphically shows how user roles are 
managed in a multi-community environment 7700. 

The separation of community 7702 and directory 7704 also allows the administration in 
5 each community to be different even though the user is shared. Consider the example 
presented earlier in this section. The supply chain coordinator's IT may control 
administration for board member reports, while the actual community member controls 
administration for the order management application. The separation allows changes to a 
user's profile in one community without impacting the user's existence in another. This 
10 is especially useful when adding and removing users. The supply chain coordinator may 
want to remove a user from the ASP order management service but still have them exist 
in the board member report application 
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Single Sign-on Definitions 

To discuss single sign-on, central policy management, and delegated administration, it is 
important to define two terms. 



Authentication - First step in single sign-on. Uniquely identify a user based on company 
20 id, user id, and password. 

Authorization - Occurs after authentication. The level of application of data access 
allowed for an individual user. 



25 Portal Management Solutions 



As the integrated supply chain concept caught on, organizations had to deal with the 
challenges of single sign-on and distributed administration. These are the same issues the 
supply chain coordinator is dealing with as they begin their initiatives. The first response 
30 of large community owners was to custom build solutions on top of their IIS or Netscape 
server-based applications, as was suggested as possible in option 1. But as organizations 
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began to build custom solutions, there were many failures or limitations on what could be 
accomplished. At the same time, the market has matured as the need for SSO and 
distributed organizations expanded to more organizations. Off-the-shelf single sign-on 
portal management solutions came to market, and many owners of large communities 
have replaced their homegrown systems with solutions based on these products, which 
have the following features: 
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User entitlement management 
Authentication with single sign-on 

Distributed and delegated user administration (group level responsibility) 
Affiliate Services (integrate ASPs) 

Centralized privilege management (one place for all applications) 
User tracking (configurable) 

Ability to link attributes for personalization to single sign-on 
Distributed and delegated portal administration 
Integration with most directory services 



Web-based Single Sign-on/Portal Management Architecture 

SSO/Portal Management products are software packages that run on their own server. 
They also require a directory to operate against. This can be either LDAP or database 
directories. 



The interaction between applications and the SSO/Portal Management server is client- 
25 server based, with the application webserver using an agent or plug-in (client) to 
reference the central policy server for user validation. 



30 



Figure 78 illustrates a schematic 7800 showing the protection of resources with a central 
policy server, a separate user directory, and the integration of affiliate sites 7802 through 
the agent client 7804. 
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Technologies Supported bv SSO Products 

Within each area of the architecture, there are multiple methods supported. Solutions can 
run on multiple operating platforms and with multiple types of user directories. Solutions 
5 can be extended with multiple development languages, support many authentication 
technologies, and operate in conjunction with many network security implementations. 

Policy Based Security 

1 0 Figure 79 illustrates a policy based security architecture 7900, in accordance with one 
embodiment of the present invention. One of the features of SSO/Portal Management 
solutions is central policy enforcement for distributed resources. Historically, policies 
and users were all managed in the same data store as the application being used. In the 
SSO model, a layer of abstraction exists where administrators manage policies in one 

15 repository and users in another. Applications then access the policy server 7902 (which 
references the policy and user repository) through an agent. The policy server returns an 
allowed and denied status. 

When purchasing an off-the-shelf product, the infrastructure above is part of the solution. 
20 The work that must be performed is setup user and policy management, and then to 
actually create the users and the policies. 

Comparison to Requested Functions 

25 In a previous section, the features requested by the supply chain coordinator's community 
were detailed along with the functions those features imply. The following table shows 
whether functions are provided by this approach along with an explanation. Table 1 8 
illustrates the various features associated with option two. 

30 Table 18 
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Feature 


Y/N 


Explanation 


SECURITY 






Lockout user after n unsuccessful 
logon attempts 


Y 


Supported 


Notify administrator of lockouts 


Y 


Supported 


On line monitoring 






Provide alternate passwords for 
lost/forgotten password situations 






Password expiration; require 
periodic password changes 


Y 


Supported 


Acceptable password length 
parameters 


Y 


Supported 


Ability to assign/select password 


Y 


Supported (not self-registration) 


Ability to transfer logon 
intelligence. 


Y 


Agent to integrate affiliate sites. 


Record all activities to the audit 
log 


Y 


Supported 


COMMUNITY 
MANAGEMENT 






Distributed community 
administration 


Y 


Basic in this option. 


Ability to add, change and delete 
users. 


Y 


Supported 


Ability to assign access to users 


Y 


Supported 


Ability to create roles or level of 
users 


Y 


Supported 


Ability to set up default levels of 
access 


Y 


Supported 


Ability to clone and/or access 


Y 


Supported with configuration 
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Feature 


Y/N 


Explanation 


rights 






Mass delete of users 






Ability to copy a user ID 






Ability to export user load 
information from member 
backend. 


N 


Supported, but not implemented 


User can be associated with 
multiple groups. 


N 


Groups here refers to organizations, 
which required customization 


HIERARCHIES 






Ability to publish rights and 
privileges across hierarchies. 


N 


No hierarchies 


Ability to authorize multiple 
levels of a hierarchy 


N 


No hierarchies 


Ability to manage access against 
hierarchies 


N 


No hierarchies 


Flexible data access and 
management. 


N 


SSO out of the box does not deal with 
application-specific access (data 
required with an application) 


Data Publication 


N 


Not supported 


User can view or access data in 
another sub-domain in their 
domain. 


N 


Not supported 


User can view or access data in 
different domain. 


N 


Not supported 


POLICY ENFORCEMENT 






Single sign on 


Y 


Supported 


Ability to integrate with affiliates 
(i.e. other 3 rd applications that 
make up the portal). 


Y 


Supported 
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Feature 


Y/N 


Explanation 


Ability to interface with other 
applications: 

The supply chain coordinator 
3 rd party 
Remote hosts 
Platform independent 


Y 


Supported 


Centralized policy management 


Y 


Supported 


REPORTING 






The following community 
management reports were 
identified: 
Master user list 
Click and view access list 
User with published data 
authorization (i.e. users in other 
domains or sub-domains. 
Usage reports 


N 


Admin can see some of this data, but it 
is not enabled to be viewed by users 
through their own application 


Lockout notification 


Y 




Online monitoring capability 






View audit log 


N 


The supply chain coordinator's admin 
only - not readily available to 
individual users 


Parameter driven reports 


N 


The supply chain coordinator's admin 
only - not readily available to 
individual users 



In comparing this chart to the one in the last section outlining option 1, there are many 
more "Yes" functions. These are in the areas of single sign-on, integration of affiliate 
sites, distributed user administration, and central policy management. What is not 
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supported in this approach are hierarchies, publishing privilege rights to other users 
outside of one's group, managing application specific data in the user profile, and 
advanced activity reporting made available to individual users. 

Product Options 

There are several companies who provide software and services centered around this 
approach. These companies include Netegrity, Securant, enCommerce (a division of 
Entrust), and Oblix. For the supply chain coordinator, GE recommends that Netegrity 
and Securant be evaluated for the portal management software solution. This is as a 
result of research conducted for GE Global Exchange Services deployments already in 
production and implementation experience in the General Electric Company. 

There are several differences between the two products in architecture more than 
function. Netegrity is the market leader and has the most large scale implementations, 
including providing the base architecture for GE's global supplier portal and several other 
GXS solutions where the requirements were similar to the supply chain coordinator's. 
Securant waited longer to go to market, but by many accounts has a better future vision 
and more elegant architecture. Another significant different is that Netegrity is very 
focused on development around LDAP, where Securant uses database technology as the 
base under their directory structures. 

In order to compare the two products, data is provided below from Giga Information 
Group. The following is a list of criteria used by Giga Information Group to evaluate 
web-based single sign-on products: 

Multiple Authentication Types — All SSO products support passwords, of course. But 
some may support additional authentication types, such as biometrics, digital certificates, 
tokens or smart cards. 
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Authentication Method — The method differs from the type by representing the 
underlying authentication architecture. How well does the product handle the registration, 
suspension, etc. 
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Quality of Administration — In the case of employee SSO, the emphasis is placed on 
easy-to-use administrative console, intuitive commands and integration with user data 
repositories already in existence (e.g., human resources databases). Web SSO products 
are evaluated similarly, with the added point of distributed, subordinate administration - 
allowing multiple administrators to manage subsets of the user population. 

Breadth of Supported Applications — How diverse are the supported target 
applications and platforms? 



Granular Access Management — The Administrative console should permit the 
15 administrator to control authorization not only to certain applications, but also under 
certain conditions. Web SSO products are heavily weighed on this point. 



Robust Architecture — How fault-tolerant and efficient is the underlying architecture of 
f if the product itself? How well does it scale to loads and to geographic distances? 



20 

Use of Directory Services — To what extent does the product rely on directories, 
compounded with the ability of that directory to be used for other purposes 
simultaneously? 

25 End User Ease of Use — For employee SSO, this refers mainly to the familiar desktop 
experience and the elimination of normal log-in interruptions. For Web SSO users, this 
refers to the degree to which the user's desktop browser is modified in any way. 

Vision — Also known as product road map, which vendor projects the most visionary 
30 use for its products during the next five years? 



196 




Costs and Timelines 

For option 2 the assumption is that the security management solution software provides 
single sign-on, authentication management, entitlement management, distributed 
5 administration and affiliate services. Table 19 shows list of assumed functionality for the 
purpose of cost and level of effort estimation: 



Table 19 







Ontion 2* N^ttwitv or Seen rant S ecu ritv Management Solution 

K^rlJl-lKrMM. J** llWll/jlJ ILT XJrn. UWU1 (till U Will llj lTltlU HgVlUVU I kJVlUUUU 




Feature List 


Software 




Distributed User 


Option 1 plus user registration service with the following directories 


ill 


Administration 


technology: Netscape LDAP, NT Domains, Novell Directory 






Services, SQL Database, Oracle Internet Directory 




Administrative 


Basic User/Session/Application tracking 


, % 

t;: -i 
E i, ; 
? i*f 


Audit Trail 






Access 


Web interface to administer authorization and access control, secure 




Management 


portal management 


= &f 
s : li 


Logon/Password 


Basic authentication schemes, X.509, tokens, Forms, RADIUS, 


M 


Management 


certificates and SSL 




Reporting 


Basic reporting from system/software logs 




Policy 


Centralized basic policy-based management 




Enforcement 






Data Management 


Basic access rules on data 
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Hardware 

Once hardware is acquired, the supply chain coordinator may need to host the solution on 
15 a dedicated platform. This may require at least two standard server class machines, one 
for production and one for pre-production/backup. The supply chain coordinator may 
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choose to have a third box as a dedicated development and test environment or dedicated 
backup. 

Product Training 

For all developers who customize and build on the security platform, training may be 
required. The estimated time for training is a month per applied resource. 

Resources 

The following is an estimated list of resources that may be required to install and 
configure the security management solution software to provide the functionality in the 
table above. 



15 • 1 proj ect manager 

• 1 system integrator 

• 1 QA 

• 1 security consultant 

20 Estimated Project Length 

Estimated project length is 2-3 months. 

Option 3: Security Management Solution Software + Custom Administration 

25 Option 3 addresses many of the delegated and self-administration requirements the 
supply chain community demands. While the product itself provide the ability to 
distribute administration features, most of these center around assigning access privileges 
for applications or resources. It does not take into account distributed administration of 
user specific data (preferences and data attributes) that may be required by the 

30 applications behind the supply chain portal. The basic product also does not capture and 
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consolidate events from multiple applications and make them available for viewing by 
individual users and group administrators. 

Figure 80 is a flowchart of a process 8030 for a secure supply chain management 
5 framework. A plurality of users including suppliers, distributors, and stores of a supply 
chain are registered utilizing a network in operation 8032. The registered users are 
maintained on a list in operation 8034. Data from a plurality of stores of the supply chain 
is collected utilizing the network in operation 8036. The list is updated to add, edit, and 
delete the users utilizing the network in operation 8038. When a request (which includes 
10 an identifier) for access to the data is received utilizing the network in operation 8040, the 
identifier is compared against the list in operation 8042 and a network-based interface is 
Q displayed in operation 8044 for allowing access to the data upon the successful 

comparison of the identifier against the list. 
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15 In one aspect, the identifier includes a password. In another aspect, the data is encrypted. 
In a further aspect, the list is updated upon receipt of a notice from at least one of the 
stores. In an additional aspect, only certain data is displayed based on the user being one 
of the suppliers, distributors, and stores. In one aspect, the network includes the Internet. 

20 Setting Up a Unified Directory 

Directory structure may be useful for extending the security management solution. The 
exact design of the directory may be the first task for an organization implementing the 
extended functionality for the supply chain coordinator. Directory design is beyond the 
25 scope of this engagement, but the following outlines the items to create directory 
structures that support the supply chain coordinator's needs. 

1. Determine the Directory's Goals 

2. Plan the Directory Data 

30 3. Identify all data to go into the directory 

• Determined where the data may be mastered 
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• Determine who manages the data and who exactly may be allowed to update data 

• Determine who can use the data and form 

• Document the results 

5 In identifying data, the question of what should go into the directory should be asked. 
The answer is data that is read often and written little: 

• Data that can be expressed in simple object-attribute-value form 

• Data useful for more than one audience 

10 • Data accessed from more than one physical location 

; | It is also important to ask what should not go into the directory. The answer is data that 

££e changes frequently, Large and unstructured chunks of data designed for file systems, ftp 




servers, web servers, or relational databases, data that requires sophisticated database 
1 5 operations to be accessed and manipulated. 
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4. Plan the Directory Schema 

• Identify all attributes needed to support a directory 

• Identify which attributes should be indexed 

• Identify all object classes needed to support a directory data 

• Determine if and how you may extend the schema 



Document 



The questions in planning the schema are how may the data be represented? 
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What is the authoritative source of each data element 



Who is the owner for each element in the schema 



How is the data element updated in the directory and how often 
How often is the data accessed and in what way 



30 



Would indexing the data element be productive for speeding up lookups? 
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5. Plan the Directory Tree 

6. Plan the Security Policies 

7. Plan for Replication and Referrals 

8. Create the Implementation Plan 

Extending the Directory to Meet Application Specific Requirements 
Adding User Specific Attributes 

Portal management solutions based on a directory include the ability to create extended 
attribute columns in the schema. Extended attributes can serve a number of uses by 
applications. Two common examples are user preferences such as language and local 
time. Once the directory structure designed by the process above is in place, the supply 
chain coordinator may need an application to allow users to manage their preferences and 
other data to be used by applications. 

Figure 81 shows a schematic with attribute setting through a web interface 8100. The 
figure shows an attribute 8102 that can be set through a web interface 8100. The 
preferences are saved in the directory attributed 8104 to company_id and userjd 8106 
(which together form a unique user in the system). Another example of attribute data 
pertaining to the supply chain applications could be to store single or multiple retailers a 
specific user can access data for. 

For each attribute category the supply chain coordinator decides to include in the 
directory store, administration screens maybe required to add, modify, or delete the 
attribute data. 

Advanced User Privileges for Extended Directory Use 
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Once the application functionality specified previously exists, a new community 
management challenge presents itself. The question of who can access the new 
administrative features and what attributes they can update must be answered. 

What makes this challenge much greater than managing privileges in Option 2 is that 
with the base configuration, privilege models are more simplistic and for the most part 
reserved for administrator users. Now that application-critical attribute data is being 
maintained by users themselves in a more distributed model, it may be helpful to make 
sure that the privileges to access applications and data are distributed properly. 

At creation time, a user can get the following privileges: 

Default privileges (defined by group type, user type and creator privileges, they are the 
intersection of these three sets of privileges, what is common to all of them). 

Allowable privileges (creator privileges) These privileges are those, which the creator 
has, but are not included in the users default privileges. 



Default privileges are assigned to the user at creation time (a trigger should be 
20 automatically fired), the allowable privileges may be granted if the creator choose to. 
The user privileges can be modified later by a user with sufficient privileges. That 
modifier user can revoke any privilege, (no matter if he/she has or does not have that 
privilege) and can grant only the privileges he/she has. 

25 The administrative interface needs to be extended to allow for the addition of allowable 
features. The process by which default privileges may be assigned also needs to be 
customized in this approach. Once the more sophisticated privileges are in place, the 
update preference process is enhanced to check for proper access level. Figure 82 
illustrates a flow diagram 8200 for assigning default privileges. 

30 
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Once this information is stored and updated in the user profile 8202, the application 
needs to update the current session. This requires that the session object be able to 
handle the attribute information so that it can be passed to applications that need it later 
(another piece of work). 

5 

Finally, though outside of the scope of the portal management solution, the applications 
that may use the extended attribute information must be programmed to correctly receive 
the information and put in into its application session. 

10 Custom Privilege Templates 

Another way to extend the security management solution to make administration easier is 
privilege templates. There should be privilege templates for each domain in the system. 
These focus on applications a certain type of user can access. For example, certain 
1 5 functions are only for the supply chain ember users. If there are certain things a user type 
can perform, making the administrator setup these privileges over and over again for each 
new user is a waste of time. Setting up a template for all users of that domain makes 
more sense. The domain privilege templates are created and maintained (add / delete 
privilege) by admin users. 

20 

Throughout the community there are many users who share a similar job function. Some 
of these differ within a domain, but some also are the same throughout the system. For 
example, every group may have an administrator regardless of domain. In order to save 
time in user setup, a user should be able to be assigned a role type that carries a certain 

25 number of privileges with it. The role may be used as a template to setup users, or the 
role might actually become an entity that privileges are assigned to, and whereby a user 
inherits those privileges by being attached to the role. Some roles may be setup for use 
across the system by the system administrator; the domain where the role is used may 
bound these. Other roles might be setup in a domain or group, depending on how much 

30 flexibility the supply chain coordinator decides to include in the solution. 
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The final piece to what a new user can be granted deals with the fact that a user can add 
only privileges that he/she was granted with, however he/she can delete any privilege that 
the grantee template contains. 

5 Figure 83 shows a Venn diagram 8300 illustrating the intersection of privileges, i.e. 
domain 8302, group 8304, and granted 8306, for a new user. 

There should be a user interface for maintaining the tables where domain and role 
templates are stored. After a new domain or role is created in the system, a UI page is 
10 needed that allows the creator to attach newly created templates of privileges to the new 
domain or role. The creator can grant only his/her privileges. 

Combined Activity Logging and Reporting 



15 Another feature the supply chain community asked for was a single place to view the 

)4 activities their employees perform in supply chain applications. In option 1 , this was not 

I'll 



possible, as there was not a single view of a user across applications. In option 2, there 
was single sign-on and the infrastructure to capture some user information across 
applications, but very little customization performed to take advantage of the 



^1 20 infrastructure. 



In option 3, two important functions are added. First, development is performed to 
increase the number of events that are captured about the user. This includes integration 
to the third party ASP applications to retrieve a set of user initiated events. These events 
25 are either stored in the security solution logs or in the supply chain coordinator's 
database. 



The second part of this development effort includes building online visibility to the 
events captured for a group's administrator. This function gives the distributed 
30 community administrators the tracking capabilities they have asked for. These online 
views and reports should allow a group admin to see activities, both application access 



204 



related and perhaps even user actions within an application (depending on what the third 
party ASP applications can provide). There was also discussion during the workout 
sessions that the system might provide visibility for users within a company, with 
possible views including all registered users from their company. 

5 

Comparison to Requested Functions 

In a previous section, the features requested by the supply chain community were detailed 
along with the functions those features imply. Table 20 shows whether functions are 
10 provided by this approach along with an explanation. 



Table 20 
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Feature 


Y/N 


Explanation 


h i 

Pi 


SECURITY 






Si: S 
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$ 
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I. 


Lockout user after n unsuccessful 
logon attempts 


Y 


Supported 




Notify administrator of lockouts 


Y 


Supported 




On line monitoring 






Ml 


Provide alternate passwords for 








lost/forgotten password situations 








Password expiration; require 


Y 


Supported 




periodic password changes 








Acceptable password length 


Y 


Supported 




parameters 








Ability to assign/select password 


Y 


Supported (not self-registration) 




Ability to transfer logon 


Y 


Agent to integrate affiliate sites. 




intelligence. 








Record all activities to the audit 


Y 


Supported 




log 







205 




Feature 


Y/N 


Explanation 


COMMUNITY 
MANAGEMENT 






Distributed communitv 
administration 


Y 


Basic in this ontion 


Ability to add, change and delete 
users 


Y 


Supported 


Ability to assign access to users 


Y 


Supported 


AbiHtv to create roles or level of* 
users 


Y 


Sunnorted 


Abilitv to set im default levels of 
access 

V**/»^ VWv 


Y 


Sunnorted 


Abilitv to clone and/or access 
rights 


Y 


Sunnorted with confisuration 


Mass delete of users 






Abilitv to cotw a user IT) 






Ability to export user load 

information from mptnhpr 
backend 


N 


Supported, but not implemented 


User can be associated with 
multinle erouns 


N 


Groups here refers to organizations, 
which reauired customization 

W JLJIJIWJLJ. 1 VVt till VV1 V Ww IV/lillJLriil'lVll 


HIERARCHIES 






Abilitv to nublish rights and 
privileges across hierarchies. 


N 


No hierarchies 


A hilitv tn 5nitnon7p mnltinlf a 

levels of a hierarchy 


N 


Nn nifriirf^riif^c 


Abilitv to manage access against 
hierarchies 


N 

JL ^ 


No hierarchies 


Flexible data access and 
management. 


Y 


Custom extensions to support 
application specific data needed to 
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Feature 


Y/N 


Explanation 






control data access 


HATA PT TOT TP A TTfYM 






User can view or access data in 
another sub-domain in their 
domain. 


N 


Not supported 


user can view or access oaxa m 
different domain. 


XT 
IN 


i\oi supporceu 


POLICY ENFORCEMENT 






Single sign on 


Y 


Supported 


Ability to integrate with affiliates 
(i.e. other 3 rd applications that 
make up the portal). 


Y 


Supported 


Ability to interface with other 
applications: 

, i ii* j* j. 
the supply chain coordinator 

3 party 

Kemote nosts 

Platform independent 


Y 


Supported 


Centralized policy management 


Y 


Supported 


REPORTING 






The following community 
management reports were 
identified: 
Master user list 
Click and view access list 
User witn puoiisned data 
authorization (i.e. users in other 
domains or sub-domains. 
Usage reports 


Y 


Custom 
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Feature 


Y/N 


Explanation 


Lockout notification 


Y 




Online monitoring capability 






View audit log 


Y 


Custom 


Parameter driven reports 


Y 


Custom 



From the comparison chart, this is a pretty comprehensive alternative. Still missing are 
the most complex community management items such as hierarchies and data publication 
5 across domains, but most other items are supported by this alternative. 



ri Costs and Timelines 

,, — 

, 

M 

v, 

M For option 3, the assumption is that the security management solution software provides 

i.fj 

L\ 10 more advanced administration features, self-administration, improved session tracking 
\ * and event capture, detailed reporting, and custom policy extensions. Table 21 shows a 

! si 

list of assumed functionality for the purpose of cost and level of effort estimation. 

1 1 Y$ 



Table 21 



Feature List 


Option 3: Security Management Solution Software + Custom 
Administration 


Distributed User 
Administration 


Option 2 plus, Custom approve/reject registration, grant/deny 
access to applications, grant privilege, modify user profiles, reports 


Administrative 
Audit Trail 


Custom User/Session/Application tracking 


Access Management 


Web interface to administer authorization and access control, 
secure portal management and custom agents. 


Logon/Password 


Basic authentication schemes, X.509, tokens, Forms, RADIUS, 
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Management 


certificates and SSL. 

Custom notification and online monitoring 


Reporting 


Custom reporting integrated with monitoring systems 


Policy Enforcement 


Custom extension of the policy 


Data Management 


Custom extension 



Software and Hardware 



From a cost standpoint, Option 3 assumes that Option 2 has been implemented. 
Therefore, additional software license fees are not required. Additional hardware is 
probably not required, unless the load on the directory requires a separate installation of 
the supply chain coordinator decides to implement a reverse proxy server. 

Resources 

The following is an estimated list of resources that may be required to install and 
configure the security management solution software, develop custom administration, 
and develop custom reports to provide the functionality in the foregoing table. 

1 project manager 
1 business analysis 

1 system integrator 

2 web/database developers 
1 QA, security consultant 
Estimated Project Length 

The estimated project length is 4-6 months (Dependent on completion of option 2) 
Option 4: Adding Advanced Community Structures 

The supply chain coordinator has a very unique community with real-world issues that 
defy standard organizational definitions. No two organizational structures or ownership 
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arrangements are the same. Yet being able to map the real world may be useful for fully 
meeting the community's requirements without clumsy workarounds. 

The following section describes several custom additions that could be developed to push 
5 out community management to end-users and allow them to manage their web-based 
applications in a way matching their real-world business organization. Also presented is 
a way to dynamically manage the relationships between supplier, distributors, and 
retailers in place of a cross-reference method that requires constant update for application 
data access. 

10 

Each of the following would be custom developed application. While they would 
integrate heavily with the portal management solution and directory structure in options 2 
3 and 3, they would be stand alone applications that would run in their own environment. 

!.! 

?1 1 5 Creation of Hierarchies for Application and Data Access Control 

W Hierarchies are a way of representing real- world structures inside of an application. The 

3 purpose is to provide a more flexible way to manage the relationships between entities 

?f and other entities, entities and users, and users and data. Hierarchies are very complex to 

5 

y 20 implement, especially in a many to many community such as the supply chain 
2 coordinator has. If implemented properly, however, they can provide group owners a 

way to manage their application and data controls that matches the way they see their 
own businesses and maps how they control functions in real life. This section attempts to 
lay out how hierarchies are implemented, maintained, and how they can be used to 
25 enhance privilege storage. 

Creating and Managing Domains 

The first step in creating a hierarchy is to create domains. Domains are the different 
30 types of groups that may exist in the portal, with each one requiring different business 
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rules for privilege assignment. An application function is needed to add a domain or 
remove a domain as shown below. 

Figure 84 illustrates a diagram 8400 showing a system 8402, supply chain member 8404, 
retail manager 8406, the supply chain coordinator 8408, supplier 8410, and distributor 
root nodes 8412. 

Creating and Managing Groups (Corporate Organizations) 

Once domains exist, the next step is to setup groups within a domain. An example is the 
supplier domain. There are many different supplier companies, and each of these may 
have their own group (to control data access rights) even though they all share common 
application access rights. To technically describe groups under the top level domain, the 
term node is used. Nodes can be single level in nature or built in n-tiered structures, with 
each node having a parent node. In the case of a top level group, the parent node is the 
domain itself. An application function to add/modify/delete child nodes is required to 
add groups as shown in the diagram below. 

Figure 85 illustrates another diagram 8500 showing groups 8504 within domains 8502. 

Groups exist within a domain. Therefore no matter what roles are created within a group, 
they are bounded by the privileges granted to a domain. 

Adding Users to a sub-group (node) versus to companies 

In a directory based security model (LD AP or NT), users typically belong to companies 
(groups). In the move to n-tiered hierarchies, there is also a move from the directory used 
by the SSO product to a relational database. This is because referential integrity is 
required to take full advantage of and properly manage hierarchies. By only allowing top 
level groups (not allowing an n-tired hierarchy), the hierarchies are easily synched to the 
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companies in the directory. If the supply chain coordinator chooses to enable sub-groups, 
however, users belong to nodes and not companies, and the path to the top node of each 
hierarchy instance identifies the corresponding company in LDAP. An n-tier hierarchy is 
shown below. 

Figure 86 shows still another diagram 8600 showing hierarchies 8602, in accordance with 
one embodiment of the present invention. 

If n-tiered hierarchies are enabled, the management feature must also allow for nodes to 
be moved from one parent to another, as well as the ability to take a node and all nodes 
attached below it and move them together. Figure 87 shows a process 8700 for hierarchy 
management, in accordance with one embodiment of the present invention. 

Figure 87 shows that this is an involved process requiring proper design, custom 
implementation, and testing. 

Hierarchy Linkages for Data Access Control 

In the initial stages, all information distributed by the supply chain coordinator to 
suppliers and distributors may be packaged by the supply chain coordinator. For 
example, in the pilot, the supply chain coordinator maintains a list of stores served by a 
specific distributor. When a report runs, it runs for all retailers associated in the cross- 
reference table to that distributor. To make sure information is correct, those cross- 
reference tables must be up to date. This approach also means that the supply chain 
coordinator is in control of what data can be viewed by a distributor, and there are very 
few controls over who within a distributor organization can view retailer information. 
The supply chain member has very little control over their data in this scenario, and the 
supply chain coordinator has a very high management overhead in this data exchange. 

To perform more complex data access control, the supply chain coordinator may choose 
to implement linkages between organizational hierarchies. As described below, 
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hierarchies can be added to each domain (The supply chain coordinator, supplier, 
distributor, supply chain member, retail manager) to add application access flexibility. 
For data purposes, there can be links between nodes of one hierarchy and another. The 
most common usage of this would be a distribution center to a store. 

Example: Looking at a large supply chain member and a distributor that serves them. A 
generic structure is shown in Table 22. 



Table 22 



supply chain member 


Distributor 


Corporate Group 


Operating Group 


Division 


Region 


State 


Distribution Center 


City / Area 


Retailers 


Retailer 





Figure 88 depicts a hierarchy 8800 in the supply chain portal management, in accordance 
with one embodiment of the present invention. In the supply chain members hierarchy, 
all retailers 8802 are attached to a level of node representing metropolitan areas 8804. 
From the diagram before, each retailer of a supply chain member is associated with one 
(and only one) distribution center of a distributor. This allows a supply chain member to 
allow access for a distributor to access information for all retailers that they serve. But 
rather than assigning access for each retailer on its own (maintaining a cross-reference), 
the can leave the access control to the linkages created. This assumes that the linkages 
are maintained properly, but the advantage is that distributor access could be restricted to 
a level below the top level node without the need to update the access privilege every 
time a retailer status changed. The next section describes how this is technically 
implemented. 
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Hierarchy linkages for Data Publication 

Each point in a hierarchy is a "node". Each node has a number or value assigned to it. 
This NODE ID is numeric, unique system-wide and would enable the supply chain 
5 coordinator hierarchy system to clearly and unambiguous define in the application any 
location in the supply chain member, supplier, distributor, or retail outlet manager 
hierarchy. 

Figure 89 illustrates the retail manager 8900 as part of the supply chain coordinator 
10 hierarchy 8902, in accordance with one embodiment of the present invention. 

The node ids or attributes become important in privilege setup. For example, initially a 
user named "Joe" might be part of the group "Restaurants." In a normal association, Joe 
Q would be able to see all data that belongs to his group. The access to data could be 

1 5 restricted in option 2 or 3, but that would have to be handled by the applications or 
through extended attributes with the actual store numbers in the portal management 
solution. There was not a concept of inherited data access or restricted data access 
through the use of nodes. 
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20 Now, assume that Joe is really a field auditor in the west restaurant manager division. As 
M the restaurant manager admin, you want to setup Joe so that he can only access data for 

the West region, and cannot see the other divisions data. In the database portion of the 
security management system, the company id (restaurant manager) in the company id is 
replaced with a group id. Because the group id is a sub-group of the top level restaurant 
25 manager node, it can be associated back to the companyjd that is stored in the directory. 

Because Joe now belongs to group 503 and not group 500, he can only see data for 
restaurants from his node in the hierarchy and downwards. Note Table 23. 

30 Table 23 
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Group 


User Id 


User 


Priv. Id 


Grantor 


Restricted 


Id 




Type 




Id 


Node Id 


503 


Joe 


the 


View 


500 








supply 


Order 










chain 


Data 










member 









Another case might be that while Joe works in the West Region, he actually only audits 
restaurants in the Tempe Metropolitan area. The columns can be added to the privilege to 
include other information such as a node that further restricts data access. With the 
privilege below, Joe can now only view order data for restaurants below node 506, even 
though there are more restaurants under the scope of node 503. Note Table 24. 

Table 24 



Group 


User Id 


User 


Priv. Id 


Grantor 


Restricted 


Id 




Type 




Id 


Node Id 


503 


Joe 


supply 


View 


500 


506 






chain 


Order 










member 


Data 







The concept of extending columns in the privilege store becomes very important when on 
organization has a requirement to grant access to applications and data to users in another 
group or another domain. 

Granting Privileges Across Groups 

Introduction 
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The requirement to grant access from one group to a user in another group comes from 
the complex ownership arrangements that the supply chain members have. 



4 
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The supply chain members are the owners of the data (retailer information). They can 
publish (grant) their privileges to users in other organizations. The design for this is that 
supply chain members publish data in their hierarchy by: 

• Granting access to retailers that belongs to their group or to groups downward in 
their (supply chain member) hierarchy. 

• Granting access to specific retailers (many retailer ids). 

• Granting access to retailers within a state or a zip code. 



h 4 15 Example: 
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The grantor that belongs to 345- supply chain member node publishes the privilege to 
view order data to user Joe belonging to 123 supply chain member node. What Joe can 
see, so far, are the retailers the granter can see in his hierarchy, "Rl", "R2", "R3"and 



The grantor can narrow down the publishing by specifying a node in his hierarchy, let us 
say node 456. At this point, the user can see data for "Rl", "R3" and "R4" 



25 A "state" or "zip code" can narrow more the publishing. 



Figure 90 is a schematic showing the process 9000 by which cross-domain access rights 
are granted. 

30 Table 25 shows an example of how the privilege would be written to the central policy 
management. 
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Table 25 



Group 


User Id 


User 


Priv. Id 


Grantor 


Restricted 


Restaura 


Attributes 


Id 




Type 




Id 


Node Id 


nt Id(s) 


(state/zip) 


123 


Joe 


supply 

chain 

member 


View 
Order 
Data 


345 


456 
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5 Just the node numbers are stored in the directory. When the user is authenticated and 
accessing applications that need a store list in order to properly enforce data access rules, 
the custom application written in this alternative must access the hierarchies in the 
database. From the database, the application translates the intersection of the node ids 
into a list of valid stores that the user may perform the granted functions. This retailer list 
10 is then returned as part of the header strong to the resource requested. 

You could even make this more granular by adding attributes for state or zip code 
associated with the nodes (especially the lowest node, which is a retailer). 

15 Publication Functionality 

The following is a list of publication functionality from a supply chain member point of 
view. 

20 Publish any privilege a user has (and my data span of control) to users that need to 
perform actions for my retailers. 

Publish all my privileges a user have (and my data span of control) to users that need to 
perform actions for my retailers (mainly for equal partners). 



25 



Revoke user publication. 
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Figure 91 is a diagram 9100 that shows a process flow for an administrative function. A 
publication can not be modified, it has to be deleted and then publish again. As with 
other custom developed community management functionality, a management interface 
5 to for granting privileges is required. 

Publication Business Rules 

A supply chain member can grant access to retailers that belong to their group or to 
groups downward their hierarchy. A user can see only items at retailer level if he/she got 
"privilege" published " to him/her. The supply chain member nodes and retailer ids 
should not be mutually exclusive, as a node can be specified but a retailer may also be 
specified. 

Retailer ids and attributes should be mutual exclusive, either one can be specified, but not 
both. This is because attributes are restrictive, so by default any store specified must also 
have that attribute as part of it. 

Only the grantor can revoke data publication. 

The supply chain member does not publish data to users that belong to supplier or 
distributor hierarchy. 

Suppliers or distributors can see data based on the retailers linked to their hierarchy 
without the supply chain member specifically publishing data (assuming the application 
permission has been granted to the supplier/distributor domain by the supply chain 
coordinator). There is no need for a supplier/distributor to see another 
supplier/distributor hierarchy data. 

The supply chain member can publish data to the supply chain member users. 
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The supply chain members publish data to another supply chain member user only if the 
user is not in the same hierarchy with the grantor or if the user is in another branch of the 
hierarchy than the grantor. 



Historical Requirements for Retailer Linkage 



if -j; 
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A very complex customization of the directory attributes would be to bound all privileges 
by start and end dates. The reason behind this optional function is that retailers often 
change hands. It was expressed in the workout sessions that members may need to view 
10 historical data for a specific retailer (from both the supplier/distributor side as well as the 
supply chain member side) even if they not currently own or serve that retailer. There are 
also legal requirements that may require this ability. Table 26 illustrates an example of 
this privilege. 

15 Table 26 



Group 


User Id 


User 


Priv. 


Grantor 


Restricted 


Retailer 


Attributes 


Start 


End 


Id 




Type 


Id 


Id 


Node Id 


Id(s) 


(state/zip) 


Date 


Date 


123 


Joe 


Suppl 


View 


345 


456 






1-1- 


1-1- 






y 


Order 










2000 


2001 






chain 


Data 


















memb 




















er 
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As the number of attributes that need to be used by the application or translated into other 
information such as retailer numbers increases, so does application load. There are 
significant impacts on application performance and ease of use, as well as maintainability 
of both the portal management solution and the applications. 



Auto associate store information 
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Figure 92 is a flowchart of a process 9230 for updating information in a supply chain 
management framework. A plurality of stores of a supply chain are registered utilizing a 
network in operation 9232. The registration includes receiving first identification 
information. Data is collected from a plurality of stores of the supply chain utilizing the 
network in operation 9234. This data relates to the sale of goods hy the stores and 
includes second identification information more recent than the first identification 
information. Access to the data is allowed utilizing a network-based interface in 
operation 9236 so that in operation 9238 the first identification information can be 
compared with the second identification information in order to allow for the updating of 
the registration of the stores based on the comparison in operation 9240. 

In an aspect, the updating includes updating the first identification information to include 
the second identification information. In another aspect, the updating includes updating a 
distributor assigned to the stores based on the comparison. In further aspect, the first 
information includes a store identification number. In one aspect, the registration is 
further updated based on the data. In an additional aspect, the network includes the 
Internet. 

The supply chain coordinator receives a load of updated retailer information from the 
retailer manager. This information is currently batch loaded into the SQL database and 
updates are made to tables matching retailers to suppliers, distributors, and supply chain 
members. 

A desire is for the supply chain coordinator to automate this maintenance in the portal 
management solution as well. This is straight forward if the supply chain coordinator 
continues to use straight cross-reference between retailers and suppliers/distributors as 
the same tables may probably be accessed by the applications to determine data access in 
the application. But if hierarchies are used, there may need to be a custom application 
written to apply the following business rules. 
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When a new retail outlet is added, the application should check to see if that retailer 
already exists. If it does not, a new retailer entity should be auto-added to the proper 
group/ the supply chain member node. 

5 Each time new retailer information in the address field arrives, the application may 
compare the new information to the retailer address information to see if data has 
changed. If yes, the retailer information is updated. 

If the retailer is moved from a group node (deleted or reassigned) and it is the last retailer 
10 attached to a group node, the group node and corresponding supply chain member should 
be auto-deactivated. 



Each time new retailer information arrives, the retailer's group/supply chain member 
information should be compared with the group/supply chain member # the retailer is 
^1 1 5 already associated to. If it is different, the retailer should be reassigned (re-linked) to the 
appropriate group/supply chain member node. The Auto-add/delete processes may run as 
appropriate. 



One issue may be how to auto-associate a retailer to the proper place in a node. In the 
20 design phase, available data elements should be examined to see if it is possible. If not, 
then there should be an "unattached" node not visible to applications outside of the 
hierarchy management. When the supply chain coordinator adds a retailer to a supply 
chain member, that member could assign it to the proper hierarchy point through the 
distributed administration. 

25 

A second issue may be where to associate the new retailer to the distributor or supplier 
node. There may the ability to pull attributes from the information the supply chain 
coordinator puts in their database (distribution center number or supplier ship from 
location). If an attempt is made to auto-associate the new retailer to other domains 
30 beyond the supply chain member's, a check process may be required to make sure the 
auto-association is correct, otherwise unauthorized data access could occur. 
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Comparison to Requested Functions 

In a previous section, the features requested by the supply chain coordinator's community 
were detailed along with the functions those features imply. Table 27 shows whether 
functions are provided by this approach along with an explanation. 



Table 27 



Feature 


Y/N 


Explanation 


SECURITY 






Lockout user after n unsuccessful 
logon attempts 


Y 


Supported 


Notify administrator of lockouts 


Y 


Supported 


On line monitoring 






Provide alternate passwords for 
lost/forgotten password situations 






Password expiration; require 
periodic password changes 


Y 


Supported 


Acceptable password length 
parameters 


Y 


Supported 


Ability to assign/select password 


Y 


Supported (not self-registration) 


Ability to transfer logon 
intelligence. 


Y 


Agent to integrate affiliate sites. 


Record all activities to the audit 
log 


Y 


Supported 


COMMUNITY 
MANAGEMENT 






Distributed community 
administration 


Y 


Basic in this option. 
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Feature 


Y/N 


Explanation 




Ability to add, change and delete 


Y 


Supported 




users. 








Ability to assign access to users 


Y 


Supported 




Ability to create roles or level of 


Y 


Supported 




users 








Ability to set up default levels of 


Y 


Supported 




access 








Ability to clone and/or access 


Y 


Supported with configuration 




rights 








Mass delete of users 








Ability to copy a user ID 






SI 


Ability to export user load 
information from member 
backend. 


Y 


Custom 




User can be associated with 


N 


But goal is accomplished with publish 


1 w 

.:; 


multiple groups. 




privilege feature 


M ! 
II ; i! 


HIERARCHIES 






ill 


Ability to publish rights and 
privileges across hierarchies. 


Y 


Custom hierarchies 




Ability to authorize multiple 


Y 


Custom hierarchies 




levels of a hierarchy 








Ability to manage access against 


Y 


Custom hierarchies 




hierarchies 








Flexible data access and 


Y 


Custom extensions to support 




management. 




application specific data needed to 
control data access 




DATA PUBLICATION 








User can view or access data in 


Y 


Custom 




another group in their domain. 
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Feature 


Y/N 


Explanation 




User can view or access data in 


Y 


Publication supports this, though only 




different domain. 




real case is the supply chain 
coordinator board member, and the 
supply chain coordinator may handle 
by system admin having a custom 
feature to assign access privilege to 
users instead of publishing privilege 
across domains 




POLICY ENFORCEMENT 








Single sign on 


Y 


Supported 


h i4 


Ability to integrate with affiliates 


Y 


Supported 


^; 

!' :'s 


(i.e. other 3 rd applications that 






Ml 
ii 

8 tfil 


make up the portal). 






;. « 


Ability to interface with other 


Y 


Supported 


, ■ 
'/i 


applications: 






= |s| 
Si 


the supply chain coordinator 








3 rd party 






ii &f 


Remote hosts 






. a 


Platform independent 






M 


Centralized policy management 


Y 


Supported 




REPORTING 








The following community 


Y 


Custom 




management reports were 








identified: 








Master user list 








Click and view access list 








User with published data 








authorization (i.e. users in other 








domains or sub-domains. 
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Feature 


Y/N 


Explanation 


Usage reports 






Lockout notification 


Y 




Online monitoring capability 






View audit log 


Y 


Custom 


Parameter driven reports 


Y 


Custom 



Option 4 is the comprehensive community management solution. It requires a lot of 
customization, a lot of which occurs outside of the SSO/Portal Management solution. It 
does, however, meet all the functions specified by the supply chain community CTQs. 

Cost and Timelines 

For option 4, the assumption is that the security management solution software provides 
hierarchies, hierarchy management, and other customizations detailed in this section. 
Table 28 is a list of assumed functionality for the purpose of cost and level of effort 
estimation: 



Table 28 



Feature List 


Option 4: Security Management Solution Software + Custom 
Administration with Advanced Community Structure 


Distributed User 
Administration 


Option 3 plus Custom hierarchical community structure at 
group/role/user level, structure to structure relationship, grant 
privilege across group, advanced administration features 


Administrative 
Audit Trail 


Custom User/Session/ Application tracking 


Access Management 


Web interface to administer authorization and access control, 
secure portal management and custom agents. 


Logon/Password 


Basic authentication schemes, X.509, tokens, Forms, RADIUS, 
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Management 


certificates and SSL. Custom notification and online monitoring 


Reporting 


Custom advanced reporting integrated with monitoring systems 


Policy Enforcement 


Custom extension of the policy 


Data Management 


Custom extension 



Software and Hardware 



In 



h-4 



From a cost standpoint, Option 4 assumes that both option 2 and 3 are already 
5 implemented. Therefore, additional software license fees are not required for security 
management software. Additional hardware is probably required to support the heavy 
application and database requirements for hierarchies and their use. 

The following is an estimated list of resources that may be required to install and 
10 configure the security management solution software, develop the custom community 
management applications, and program custom data structures to provide the 
functionality in the table above. 

1 project manager 
15 1 business analysis 

1 system integrator 

2 or 3 web/database developers 
1 QA 

1 security consultant 
20 Estimated Project Length 

The estimated project length is 6-8 months (assumes completion of options 2 and 3) 



Network Considerations 



25 The supply chain coordinator can host the web portal itself, co-locate the portal servers at 
an ISP offering co-location services, or completely outsource the portal management 
solution (network and servers) to a managed service provider. 
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Hosting a Secure Portal 

From a network view, the following details best practice for configuration of network 
servers for the portal. 

One major issue may be managing a mission-critical network environment where users 
can execute transactions. The choice of ASP providers must also be a consideration. 

Managed Services 

A third option is to outsource all port, router, network and platform management. This is 
called managed services. There is a difference between managing up to the platform 
(OS) and the actual portal management solution. 

The options for managed services to the platform level are the same players. Again, 
Level 3 is the only large national player in the Miami market. They do not offer managed 
services on their own, but have a partner program to provide these services. The actual 
partner for the southern region would need to be confirmed, but it is probably the same 
company that provides this service in the mid- Atlantic region, named AiNET. A 
company like AiNET would not have knowledge of the portal management solution 
itself, but would manage everything else from a security view including attacks against 
the network and the machines. 

The next level of managed service includes actually operating and configuring the portal 
management solution. Companies in this class have resources already trained in the 
portal management solution and can take ownership of delivering the software and 
operating it for a community. Each provider has a number of partners in this area; GE 
Global Exchange Services is one of these companies. GXS provides managed Netegrity 
solutions along with others. Securant has many system integrator partners, though it is 
hard to tell who specializes in hosting and operating their solutions. 
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Application Security 

Many of the applications that may sit behind the portal may be developed and operated 
by other organizations. The following details some recommendations for applications 
built on the NT platform using Microsoft framework and for evaluating ASP provided 
applications' security. 

Recommended Policies 



• Objects must be cleared before they are reused 

• Errors during clearing must be handled in a way that ensures objects are not 
reused without clearing 

• Browser caching directives must be used for sensitive pages 

• Use of temporary files must be threadsafe 

• Temporary files must be removed when no longer required 

Approaches 

• Clear after use 

• Clear before use 

• Use finally to ensure that objects are cleared 
Vulnerabilities 



• Database connection is reused, revealing another user's data 

• Object pool includes one user's page with another's user page 

• Caching algorithm inappropriately matches a request with a response containing 
another user's data 

• Code Quality 
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Recommended Policies 



• All code must conform to a consistent style guideline 

• All code must be documented 

• Intentionally complex code must be justified 

• "Easter eggs" shall not be included in the code 

* 

Approaches 



• Use style guideline from www.microsoft.com 

• Use tools to enforce style guidelines 

• Use design reviews to catch problems early 

• Use peer reviews to prevent hidden problems 



Vulnerabilities 



• The more flaws the more likely one is to be exploitable by an attacker 

• Poor code quality can rise to the level of a security problem 

• Concurrent Programming 

Recommended Policies 

• No thread of execution within the application should be able to substantially 
affect any other thread 

Approaches 

• Synchronize access to all shared resources, including files and the session 

• Eliminate all class and instance variables, unless final 

• SingleThreadModel is not recommended for performance reasons 
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Vulnerabilities 

• Information in shared resources can be inadvertently 

• Debugging is difficult as these problems can be difficult to reproduce 

• Database Access 

Recommended Policies 

• Parameters used in database queries must not be able to modify the intended 
query 

• Results from queries must match the expected results 

• Reliance on database permissions must be minimized and explicitly identified in 
the implementation 

• The username and password used to access the database must have the minimum 
amount of privilege required by the application 

Approaches 

• Single encapsulated library for accessing databases 

• Prepared statements should be used instead of ordinary statements 

Vulnerabilities 

• Queries can be modified to reveal data or corrupt database 

• Debugging and Testing 

Recommended Policies 

• Code that is not used must be eliminated 

• System.output.println() must not be used 
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Approaches 

• Use an assertions framework 

• Keep testing code separate from production 

5 

Vulnerabilities 

• High likelihood that this code may inadvertently get enabled 

• Security Organization and Metrics 
10 • Security Roles 

• Chief Security Officer 

Develop Policy, Awareness and Training 

1 5 • Define and Continuously Revise Corporate Policy and Standards 

• Lead Company Wide Awareness and Training Program 

Continuous Security Risk Assessing and Monitoring 

20 • Enhance Assessment Tools 

• Develop Security Dashboards and Scorecards 

• Facilitate Session i 

Champion New Security Initiatives 

25 

• Resource Planning and Budgeting 

Drive Business Specific Security Strategic Planning 

30 • Align Security Strategy with Business Objectives (e-commerce) 

• Resource Planning and Budgeting 



231 



Owner of Security Measurements 

• Session i, Security Self-Assessment, Corporate and Business Specific Security 
5 Measurements 

Champion Policy Adoption and Training 

• Take Security to the Masses 
10 • Security Manager 

Lead and Own New Security Initiatives 

• Select and Package Latest Technology for New Security Initiatives 
15 • Coordinate with Businesses to Rollout Initiatives 

Deliver Company- Wide Architecture and Processes 

• Define Technical Security Infrastructure (Single Sign-On, 
20 • Intrusion Detection, Digital Certificates, VPN, etc) 

Provide Technical Consulting to Businesses 

• Assist Business to Resolve Business Specific Security Issues 
25 • Security Administrators) 

• Multiple people (Finance, IT, or distributed) 

Project Execution of Technology and Process 

30 • Responsible for Implementation in Business Site 
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Administration and Operation of Daily IT Security Activities 



• Perform IT Security Tasks, Monitor Outsourcing Vendors and Coordinate with 
3rd Parties 
5 • Security Review Structure 

The new technological infrastructure and its associated electronic reporting and feedback 
systems equips retailer management with accurate, timely, and previously unavailable 
information from the Supply Chain on sales, marketing and other performance indicators 
10 allow Supply Chain management to fully engage in managing supply and distribution 
processes and channels toward identified and agreed strategic objectives provide 
franchisees and retailers with the Supply Chain information they need to operate 
efficiently and make effective management decisions minimally impacts the resources of 
Supply Chain management. 



With Supply Chain management assuming full responsibility for managing the 
fundamentals of the Supply Chain system, Supply Chain participants are strategically 
positioned to focus on the six business priorities that have been identified: operational 
excellence, boosting sales growth, focusing resources, discovering the essence of the 



y 15 
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ij 20 Brand, image transformation and revitalizing franchisee relations. 

M 

Supply Chain Management 

Figure 93 is a flowchart of a process 9330 for managing a health and personal care 
25 products supply chain utilizing a network. Such health and personal care products 
include pharmaceuticals, cosmetics, opticals, health carpe products, etc. A network is 
utilized in operation 9332 to receive data from a plurality of health and personal care 
products outlets of a health and personal care products supply chain in which the data 
relates to the sale of health and personal care products by the health and personal care 
30 products outlets. An electronic order form is generated in operation 9334 based on the 
data for ordering health and personal care products from a health and personal care 
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products distributor of the health and personal care products supply chain. The data is 
transmitted via the network to the health and personal care products distributor of the 
health and personal care products supply chain in operation 9336. The data is also 
transmitted to a health and personal care products supplier of the health and personal care 
5 products supply chain utilizing the network in operation 9338. Additionally, activity in 
the health and personal care products supply chain is forecast utilizing the data in 
operation 9340. 

In one aspect, the data may be parsed to match each of a plurality of health and personal 
10 care products distributors and health and personal care products suppliers. As a further 
aspect, the data may be made accessible to the health and personal care products outlets, 
the health and personal care products distributor, the health and personal care products 
supplier via a network-based interface. As an additional aspect, the data may be 
accessible to the health and personal care products distributor and the health and personal 
15 care products supplier only after verification of an identity thereof. In another aspect, the 
network may include the Internet. In a further aspect, the health and personal care 
products outlets, the health and personal care products distributor, and the health and 
personal care products supplier each may forecast utilizing the data. 

20 Figure 94 is a flowchart of a process 9430 for managing an electronics and appliances 
supply chain utilizing a network. A network is utilized in operation 9432 to receive data 
from a plurality of computer product outlets of a electronics and appliances supply chain 
in which the data relates to the sale of computer product by the computer product outlets. 
An electronic order form is generated in operation 9434 based on the data for ordering 

25 computer product from a computer product distributor of the electronics and appliances 
supply chain. The data is transmitted via the network to the computer product distributor 
of the electronics and appliances supply chain in operation 9436. The data is also 
transmitted to a computer product supplier of the electronics and appliances supply chain 
utilizing the network in operation 9438. Additionally, activity in the electronics and 

30 appliances supply chain is forecast utilizing the data in operation 9440. 
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In one aspect, the data may be parsed to match each of a plurality of electronics and 
appliances distributors and electronics and appliances suppliers. In another aspect, the 
data may be made accessible to the electronics and appliances outlets, the electronics and 
appliances distributor, the electronics and appliances supplier via a network-based 
5 interface. In an additional aspect, the data may be accessible to the electronics and 
appliances distributor and the electronics and appliances supplier only after verification 
of an identity thereof. In another aspect, the network may include the Internet. In a 
further aspect, the electronics and appliances outlets, the electronics and appliances 
distributor, and the electronics and appliances supplier each may forecast utilizing the 
10 data. 

Figure 95 is a flowchart of a process 9530 for managing a transportation equipment 
supply chain utilizing a network. Transportation equipment can include such things as 
vehicles, automobiles, motor vehicles, aircraft, watercraft, and the accompanying parts 

15 and supplies for each of these, such as engine parts, maintenance supplies (filters, belts, 
hoses, etc.), washing supplies, etc. A network is utilized in operation 9532 to receive 
data from a plurality of transportation equipment outlets of a transportation equipment 
supply chain in which the data relates to the sale of transportation equipment by the 
transportation equipment outlets. An electronic order form is generated in operation 

20 9534 based on the data for ordering transportation equipment from a transportation 
equipment distributor of the transportation equipment supply chain. The data is 
transmitted via the network to the transportation equipment distributor of the 
transportation equipment supply chain in operation 9536. The data is also transmitted to 
a transportation equipment supplier of the transportation equipment supply chain utilizing 

25 the network in operation 9538. Additionally, activity in the transportation equipment 
supply chain is forecast utilizing the data in operation 9540. 

In one aspect, the data may be parsed to match each of a plurality of transportation 
equipment distributors and transportation equipment suppliers. In another aspect, the 
30 data may be made accessible to the transportation equipment outlets, the transportation 
equipment distributor, the transportation equipment supplier via a network-based 
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interface. In an additional aspect, the data may be accessible to the transportation 
equipment distributor .and the transportation equipment supplier only after verification of 
an identity thereof. In another aspect, the network may include the Internet. In a further 
aspect, the transportation equipment outlets, the transportation equipment distributor, and 
the transportation equipment supplier each may forecast utilizing the data. 

Figure 96 is a flowchart of a process 9630 for managing a home products supply chain 
utilizing a network. Home products can include, for example, building materials, garden 
equipment and supplies, home furnishings and coverings, furniture, etc. A network is 
utilized in operation 9632 to receive data from a plurality of home products outlets of a 
home products supply chain in which the data relates to the sale of home products by the 
home products outlets. An electronic order form is generated in operation 9634 based on 
the data for ordering home products from a home products distributor of the home 
products supply chain. The data is transmitted via the network to the home products 
distributor of the home products supply chain in operation 9636. The data is also 
transmitted to a home products supplier of the home products supply chain utilizing the 
network in operation 9638. Additionally, activity in the home products supply chain is 
forecast utilizing the data in operation 9640. 

In one aspect, the data may be parsed to match each of a plurality of home products 
distributors and home products suppliers. As a further aspect, the data may be made 
accessible to the home products outlets, the home products distributor, the home products 
supplier via a network-based interface. As an additional aspect, the data may be 
accessible to the home products distributor and the home products supplier only after 
verification of an identity thereof. In another aspect, the network may include the 
Internet. In a further aspect, the home products outlets, the home products distributor, 
and the home products supplier each may forecast utilizing the data. 

Figure 97 is a flowchart of a process 9730 for managing a food and beverage supply 
chain utilizing a network. A network is utilized in operation 9732 to receive data from a 
plurality of food and beverage outlets of a food and beverage supply chain in which the 
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data relates to the sale of food and beverage by the food and beverage outlets. An 
electronic order form is generated in operation 9734 based on the data for ordering food 
and beverage from a food and beverage distributor of the food and beverage supply 
chain. The data is transmitted via the network to the food and beverage distributor of the 
food and beverage supply chain in operation 9736. The data is also transmitted to a food 
and beverage supplier of the food and beverage supply chain utilizing the network in 
operation 9738. Additionally, activity in the food and beverage supply chain is forecast 
utilizing the data in operation 9740. 

In one aspect, the data may be parsed to match each of a plurality of food and beverage 
distributors and food and beverage suppliers. In another aspect, the data may be made 
accessible to the food and beverage outlets, the food and beverage distributor, the food 
and beverage supplier via a network-based interface. In an additional aspect, the data 
may be accessible to the food and beverage distributor and the food and beverage 
supplier only after verification of an identity thereof. In another aspect, the network may 
include the Internet. In a further aspect, the food and beverage outlets, the food and 
beverage distributor, and the food and beverage supplier each may forecast utilizing the 
data. 

Figure 98 is a flowchart of a process 9830 for managing a machinery supply chain 
utilizing a network. A network is utilized in operation 9832 to receive data from a 
plurality of machinery outlets of a machinery supply chain in which the data relates to the 
sale of machinery by the machinery outlets. An electronic order form is generated in 
operation 9834 based on the data for ordering machinery from a machinery distributor of 
the machinery supply chain. The data is transmitted via the network to the machinery 
distributor of the machinery supply chain in operation 9836. The data is also transmitted 
to a machinery supplier of the machinery supply chain utilizing the network in operation 
9838. Additionally, activity in the machinery supply chain is forecast utilizing the data in 
operation 9840. 
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In one aspect, the data may be parsed to match each of a plurality of machinery 
distributors and machinery suppliers. In another aspect, the data may be made accessible 
to the machinery outlets, the machinery distributor, the machinery supplier via a network- 
based interface. In an additional aspect, the data may be accessible to the machinery 
5 distributor and the machinery supplier only after verification of an identity thereof. In 
another aspect, the network may include the Internet. In a further aspect, the machinery 
outlets, the machinery distributor, and the machinery supplier each may forecast utilizing 
the data. 

1 0 Figure 99 is a flowchart of a process 9930 for managing a sporting goods supply chain 
utilizing a network. A network is utilized in operation 9932 to receive data from a 
plurality of sporting goods outlets of a sporting goods supply chain in which the data 
, S relates to the sale of sporting goods by the sporting goods outlets. An electronic order 

j ^ form is generated in operation 9934 based on the data for ordering sporting goods from a 

(jl 1 5 sporting goods distributor of the sporting goods supply chain. The data is transmitted via 
t the network to the sporting goods distributor of the sporting goods supply chain in 

il l operation 9936. The data is also transmitted to a sporting goods supplier of the sporting 

i;3 goods supply chain utilizing the network in operation 9938. Additionally, activity in the 

sporting goods supply chain is forecast utilizing the data in operation 9940. 

i J 

bj 20 

ll ' In one aspect, the data may be parsed to match each of a plurality of sporting goods 
distributors and sporting goods suppliers. In another aspect, the data may be made 
accessible to the sporting goods outlets, the sporting goods distributor, the sporting goods 
supplier via a network-based interface. In an additional aspect, the data may be 
25 accessible to the sporting goods distributor and the sporting goods supplier only after 
verification of an identity thereof. In another aspect, the network may include the 
Internet. In a further aspect, the sporting goods outlets, the sporting goods distributor, 
and the sporting goods supplier each may forecast utilizing the data. 

30 Figure 100 is a flowchart of a process 10030 for managing a chemical supply chain 
utilizing a network. A network is utilized in operation 10032 to receive data from a 
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plurality of chemical outlets of a chemical supply chain in which the data relates to the 
sale of chemical by the chemical outlets. An electronic order form is generated in 
operation 10034 based on the data for ordering chemical from a chemical distributor of 
the chemical supply chain. The data is transmitted via the network to the chemical 
5 distributor of the chemical supply chain in operation 10036. The data is also transmitted 
to a chemical supplier of the chemical supply chain utilizing the network in operation 
10038. Additionally, activity in the chemical supply chain is forecast utilizing the data in 
operation 10040. 

10 In one aspect, the data may be parsed to match each of a plurality of chemical distributors 
and chemical suppliers. As a further aspect, the data may be made accessible to the 
chemical outlets, the chemical distributor, the chemical supplier via a network-based 
interface. As an additional aspect, the data may be accessible to the chemical distributor 
and the chemical supplier only after verification of an identity thereof. In another aspect, 

15 the network may include the Internet. In a further aspect, the chemical outlets, the 
chemical distributor, and the chemical supplier each may forecast utilizing the data. 

Figure 101 is a flowchart of a process 10130 for managing a department store supply 
chain utilizing a network. A network is utilized in operation 10132 to receive data from a 

20 plurality of department store outlets of a department store supply chain in which the data 
relates to the sale of department store by the department store outlets. An electronic 
order form is generated in operation 10134 based on the data for ordering department 
store from a department store distributor of the department store supply chain. The data 
is transmitted via the network to the department store distributor of the department store 

25 supply chain in operation 10136. The data is also transmitted to a department store 
supplier of the department store supply chain utilizing the network in operation 10138. 
Additionally, activity in the department store supply chain is forecast utilizing the data in 
operation 10140. 

30 In one aspect, the data may be parsed to match each of a plurality of department store 
distributors and department store suppliers. As a further aspect, the data may be made 
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accessible to the department store outlets, the department store distributor, the department 
store supplier via a network-based interface. As an additional aspect, the data may be 
accessible to the department store distributor and the department store supplier only after 
verification of an identity thereof. In another aspect, the network may include the 
Internet. In a further aspect, the department store outlets, the department store 
distributor, and the department store supplier each may forecast utilizing the data. 

Figure 102 A is a flowchart of a process 10230 for managing an office product supply 
chain utilizing a network. Note that office products can include, for example, furniture as 
well as items typically referred to as office supplies. A network is utilized in operation 
10232 to receive data from a plurality of office product outlets of an office product 
supply chain in which the data relates to the sale of office product by the office product 
outlets. An electronic order form is generated in operation 10234 based on the data for 
ordering office product from an office product distributor of the office product supply 
chain. The data is transmitted via the network to the office product distributor of the 
office product supply chain in operation 10236. The data is also transmitted to an office 
product supplier of the office product supply chain utilizing the network in operation 
10238. Additionally, activity in the office product supply chain is forecast utilizing the 
data in operation 10240. 

In one aspect, the data may be parsed to match each of a plurality of office product 
distributors and office product suppliers. As a further aspect, the data may be made 
accessible to the office product outlets, the office product distributor, the office product 
supplier via a network-based interface. As an additional aspect, the data may be 
accessible to the office product distributor and the office product supplier only after 
verification of an identity thereof. In another aspect, the network may include the 
Internet. In a further aspect, the office product outlets, the office product distributor, and 
the office product supplier each may forecast utilizing the data. 

Figure 102B is a flow diagram of a process 10260 for managing a book supply chain 
utilizing a network. In operation 10262, a network is utilized to receive data from a 
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plurality of book outlets of a book supply chain in which the data relates to the sale of 
books by the book outlets. In operation 10264, an electronic order foim is generated 
based on the data for ordering book from a book distributor of the book supply chain. In 
operation 10266, the data is transmitted via the network to the book distributor of the 
book supply chain. In operation 10268, the data is also transmitted to a book supplier of 
the book supply chain utilizing the network. In operation 10270, activity in the book 
supply chain is forecast utilizing the data. 

In one aspect, the data may be parsed to match each of a plurality of book distributors and 
book suppliers. In another aspect, the data may be made accessible to the book outlets, 
the book distributor, the book supplier via a network-based interface. La an additional 
aspect, the data may be accessible to the book distributor and the book supplier only after 
verification of an identity thereof. In another aspect, the network may include the 
Internet. In a further aspect, the book outlets, the book distributor, and the book supplier 
each may forecast utilizing the data. 

Figure 103 is a flowchart of a process 10330 for managing a gas station supply chain 
utilizing a network. In operation 10332, a network is utilized to receive data from a 
plurality of gas station outlets of a gas station supply chain in which the data relates to the 
sale of gas station goods and services by the gas station outlets. In operation 10334, an 
electronic order form is generated based on the data for ordering gas station goods and 
services from a gas station distributor of the gas station supply chain. The data is 
transmitted via the network to the gas station distributor of the gas station supply chain in 
operation 10336. The data is also transmitted to a gas station supplier of the gas station 
supply chain in operation 10338 utilizing the network. Additionally, activity in the gas 
station supply chain is forecast in operation 10340 utilizing the data. 

In one aspect, the data may be parsed to match each of a plurality of gas station 
distributors and gas station suppliers. In another aspect, the data may be made accessible 
to the gas station outlets, the gas station distributor, the gas station supplier via a 
network-based interface. In an additional aspect, the data may be accessible to the gas 
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station distributor and the gas station supplier only after verification of an identity 
thereof. In another aspect, the network may include the Internet. In a further aspect, the 
gas station outlets, the gas station distributor, and the gas station supplier each may 
forecast utilizing the data. 

Figure 104 A is a flowchart of a process 10430 for managing a convenience store supply 
chain utilizing a network. A network is utilized in operation 10432 to receive data from a 
plurality of convenience store outlets of a convenience store supply chain in which the 
data relates to the sale of convenience store by the convenience store outlets. In 
operation 10434, an electronic order form is generated based on the data for ordering 
convenience store from a convenience store distributor of the convenience store supply 
chain. The data is transmitted via the network to the convenience store distributor of the 
convenience store supply chain in operation 10436. In operation 10438, the data is 
transmitted to a convenience store supplier of the convenience store supply chain 
utilizing the network. In operation 10440, activity in the convenience store supply chain 
is forecast utilizing the data. 

In one aspect, the data may be parsed to match each of a plurality of convenience store 
distributors and convenience store suppliers. In another aspect, the data may be made 
accessible to the convenience store outlets, the convenience store distributor, the 
convenience store supplier via a network-based interface. In an additional aspect, the 
data may be accessible to the convenience store distributor and the convenience store 
supplier only after verification of an identity thereof. In another aspect, the network may 
include the Internet. In a further aspect, the convenience store outlets, the convenience 
store distributor, and the convenience store supplier each may forecast utilizing the data. 

Figure 104B is a flow diagram of a process 10460 for managing a toy supply chain 
utilizing a network. In operation 10462, a network is utilized to receive data from a 
plurality of toy outlets of a toy supply chain in which the data relates to the sale of toys 
by the toy outlets. In operation 10464, an electronic order form is generated based on the 
data for ordering toy from a toy distributor of the toy supply chain. In operation 10466, 
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the data is transmitted via the network to the toy distributor of the toy supply chain. In 
operation 10468, the data is also transmitted to a toy supplier of the toy supply chain 
utilizing the network. In operation 10470, activity in the toy supply chain is forecast 
utilizing the data. 

5 

In one aspect, the data may be parsed to match each of a plurality of toy distributors and 
toy suppliers. In another aspect, the data may be made accessible to the toy outlets, the 
toy distributor, the toy supplier via a network-based interface. In an additional aspect, the 
data may be accessible to the toy distributor and the toy supplier only after verification of 
1 0 an identity thereof. In another aspect, the network may include the Internet. In a further 
aspect, the toy outlets, the toy distributor, and the toy supplier each may forecast utilizing 
the data. 

$ 
'% 

W Figure 105 is a flowchart of a process 10530 for managing an entertainment media supply 

ft 1 5 chain utilizing a network. Such entertainment media may include mediums with music 

J 

| and/or video stored thereon, etc. In operation 10532, a network is utilized to receive data 

y from a plurality of entertainment media outlets of an entertainment media supply chain in 

3 which the data relates to the sale of entertainment media by the entertainment media 

[j outlets. In operation 10534, an electronic order form is generated based on the data for 

y 20 ordering entertainment media from an entertainment media distributor of the 
J entertainment media supply chain. In operation 10536, the data is transmitted via the 

network to the entertainment media distributor of the entertainment media supply chain. 
In operation 10538, the data is transmitted to an entertainment media supplier of the 
entertainment media supply chain utilizing the network. In operation 10540, activity in 
25 the entertainment media supply chain is forecast utilizing the data. 

In one aspect, the data may be parsed to match each of a plurality of entertainment media 
distributors and entertainment media suppliers. In another aspect, the data may be made 
accessible to the entertainment media outlets, the entertainment media distributor, the 
30 entertainment media supplier via a network-based interface. In an additional aspect, the 
data may be accessible to the entertainment media distributor and the entertainment 
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media supplier only after verification of an identity thereof. In another aspect, the 
network may include the Internet. In a further aspect, the entertainment media outlets, 
the entertainment media distributor, and the entertainment media supplier each may 
forecast utilizing the data. 

Figure 106 is a flowchart of a process 10630 for managing an accommodation supply 
chain utilizing a network. A network is utilized in operation 10632 to receive data from a 
plurality of accommodation outlets of an accommodation supply chain in which the data 
relates to the sale of accommodation by the accommodation outlets, such as hotels, 
motels, inns, resorts, casinos, etc. An electronic order form is generated in operation 
10634 based on the data for ordering accommodation from an accommodation distributor 
of the accommodation supply chain. The data is transmitted via the network to the 
accommodation distributor of the accommodation supply chain in operation 10636. The 
data is also transmitted to an accommodation supplier of the accommodation supply 
chain utilizing the network in operation 10638. Additionally, activity in the 
accommodation supply chain is forecast utilizing the data in operation 10640. 

In one aspect, the data may be parsed to match each of a plurality of accommodation 
distributors and accommodation suppliers. As a further aspect, the data may be made 
accessible to the accommodation outlets, the accommodation distributor, the 
accommodation supplier via a network-based interface. As an additional aspect, the data 
may be accessible to the accommodation distributor and the accommodation supplier 
only after verification of an identity thereof. In another aspect, the network may include 
the Internet. In a further aspect, the accommodation outlets, the accommodation 
distributor, and the accommodation supplier each may forecast utilizing the data. 

Figure 107 is a flowchart of a process 10730 for a reverse auction in a supply chain 
management framework. Data is received in operation 10732 from a plurality of stores 
of a supply chain utilizing a network. The data relates to the sale of goods by the stores. 
An electronic order form is generated based on the data for ordering goods from a 
distributor of the supply chain in operation 10734. The data is then transmitted to 
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suppliers of the supply chain utilizing the network in operation 10736 so that the 
suppliers can offer raw products used for producing the goods at a predetermined price, 
with the price decreasing as a function of time during a predetermined duration. 



5 In one aspect, the data is parsed to match each of a plurality of distributors. In such an 
aspect, the data may be made accessible to the stores, the distributor, the suppliers via a 
network-based interface. As a further aspect, the data may be accessible to the distributor 
and the suppliers only after verification of an identity thereof. In another aspect, the 
suppliers are chosen by the stores. In a further aspect, the stores, the distributor, and the 
1 0 suppliers each forecast utilizing the data. 

Figure 108 is a flowchart of a process 10830 for tracking non-conforming goods in a 
supply chain management framework. Note that as used herein, "non-conforming goods 
includes damaged goods, mislabeled goods, and inappropriate goods, etc. Thus, it should 
15 be understood that this process 10830 may also be utilized for tracking product 

withdrawals and recalls, as well as tracking wrong products at the wrong time for the 
l M wrong purpose so that incorrectly shipped products can be promptly identified so that 

damaged product, wrong product, incorrect amounts of product are identified and 
tracked. A network is utilized in operation 10832 to receive data from a plurality of 
20 stores of a supply chain. This data relates to the sale of goods by the stores. An 

electronic order form is generated based on the data for ordering goods from a distributor 
of the supply chain in operation 10834. When the ordered goods are received in 
operation 10836, information relating to any non-conforming goods delivered by the 
distributor is entered in operation 10838 and aggregated in a database in operation 10840. 
25 The aggregated information is subsequently transmitted to the distributor utilizing the 
network in operation 10842. 
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In one aspect, the information relates to an amount of damage to the goods. In such an 
aspect, the information may also relate to a type of damage to the goods. In another 
30 aspect, a plurality of electronic order forms are generated based on the data for ordering 
goods from a plurality of distributors of the supply chain. As an aspect in this aspect, the 
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information may be parsed based on the distributor. As a further aspect, a comparison 
may be performed between the parsed data for each of the distributors. In another aspect, 
invoices may be automatically adjusted to account for the damaged/nonconforming 
goods. In yet another aspect, the goods may be salvaged, such as by being donated to 
charity, shipped back to the distributor, resold, etc. 

Figure 109 is a flowchart of a process 10900 for allocating responsibilities in a supply 
chain management framework. An agreement between a plurality of parties in a supply 
chain is received in operation 10902. A plurality of terms of the agreement are identified 
in operation 10904 which are then parsed in operation 10906 into at least a pair of groups 
including a first group of terms that includes commercial terms and a second group of 
terms that includes brand identity terms. Also, each of the terms outlines a responsibility. 
These responsibilities are allocated among the parties based on the parsing in operation 
10908. 

In one aspect, a first party is allocated the responsibilities outlined by the first group of 
terms and a second party is allocated the responsibilities outlined by the second group of 
terms. In another aspect, the parties are allocated the responsibilities outlined by one of 
the groups of terms. In a further aspect, the agreement is received utilizing network. In 
such an aspect, the terms may be parsed automatically utilizing a template. As a further 
aspect, the responsibilities may be allocated by transmitting electronic mail utilizing the 
network. In an additional aspect, the agreement includes an operating agreement. 

Figure 110 is a flowchart of a process 11000 for determining product supply parameters 
in a supply chain management framework. Product supply parameters may include 
information including the following: price/volume/weight/fob/minimxim 
quantity/payment terms/product specifications. Data is received from a plurality of 
supply chain participants of a supply chain utilizing a network in operation 1 1002. The 
received data relates to the sale of products by the supply chain participants. Product 
supply parameters corresponding to each supply chain participant are then determined 
based on information including the data in operation 1 1004. Next, corresponding product 
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supply parameters is communicated to at least one supply chain participant in operation 
11006. 

In one aspect, the product supply parameters are determined by a brand owner. In 
another aspect, the data is transmitted to the distributor and a supplier in accordance with 
the product supply parameters. In a further aspect, the network includes the Internet. In 
an additional aspect, forecasting is carried out as a function of the data and the product 
supply parameters. In another aspect, the product supply parameters indicate a price and 
an amount of the products to be ordered. In such an aspect, the product supply 
parameters may also indicate the price and the amount of the products to be ordered 
utilizing a look-up table which correlates the data to an appropriate price and amount. 

Figure 111 is a flowchart of a process 6200 for reducing costs in a supply chain 
management framework. Data is received from a plurality of supply chain participants 
utilizing a network in operation 11102. The received data relates to the sale of products 
by the supply chain participants. Rules are determined to ensure the incurrence of 
minimal costs to the supply chain participants in operation 11104 and the rules are 
applied to ensure supply to the supply chain participants at minimal cost without 
requiring the supply chain manager to take title to any goods in operation 11106. 

In one aspect, the rules are determined by a brand owner. In another aspect, the rules 
indicate a distributor to which the electronic order form is to be sent. In a further aspect, 
the rules indicate an amount of the products to be ordered from the distributor of the 
supply chain. In an additional aspect, forecasting is carried out as a function of the rules. 
In another aspect, promotion planning is carried out as a function of the rules. 

Figure 112 is a flowchart of a process 11200 for handling contracts in a supply chain 
management framework. One of a plurality of contracts is selected in operation 11202. 
The selected contract template is transmitted to a supply chain participant in operation 
11204. Data is received from supply chain participants utilizing a network in operation 
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11206. This data relates to the sale of products by the supply chain participants. The 
contract templates are then enforced in accordance with the data in operation 11208. 

In one aspect, the contract templates compliment each other. In another aspect, each 
5 contract template includes portions to be filled out by the supply chain participants. In a 
further aspect, the selected contract template is transmitted to the supply chain participant 
utilizing the network. In an additional aspect, the network includes the Internet. In 
another aspect, an indication of acceptance of the contract is received from the supply 
chain participant. 

10 

Figure 113 is a flowchart of a process 11300 for centralizing a supply chain management 
framework in which a plurality of distributors of a supply chain are registered in 
% operation 11302. Distribution management rights are then assigned from the distributors 

$ to a supply chain manager in operation 1 1304. Subsequently, data from a plurality of 

$ 

f| 15 outlets of the supply chain is received utilizing a network in operation 11306. The 

| received data relates to the sale of products by the outlets. The use of the data is 

y managed during the distribution of products to the outlets by the distributors in operation 

% 11308. This management of data use is handled by the supply chain manager. 

y 

: a 

i| 20 In one aspect, the assignment is capable of being terminated based on gross negligence 
J on the part of the supply chain manager. In another aspect, the distributors are registered 

utilizing the network. In a further aspect, the managing includes determining an amount 
of the products to be distributed to the outlets. In an additional aspect, the managing 
includes determining a timing of distribution of the products to be distributed to the 
25 outlets. In yet another aspect, the managing includes the selection of the distributors to 
distribute products to the outlets. 

Figure 114 is a flowchart of a process 11400 for providing local distribution committees 
in a supply chain management framework. A plurality of distributors of a supply chain 
30 are registered in operation 11402. Through a supply chain manager, a local distribution 
committee is organized and assigned for each distributor in operation 11406. Data from a 
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plurality of outlets of the supply chain is subsequently received utilizing a network in 
operation 11408. This received data relates to the sale of products by the outlets. The 
data is then transmitted to each of the distributors via the corresponding local distribution 
committee utilizing the network in operation 11410. 

In one aspect, the data is organized by the corresponding local distribution committee 
prior to transmission to the distributors. In another aspect, the data is processed by the 
corresponding local distribution committee prior to transmission to the distributors. In a 
further aspect, each local distribution committee utilizes the data for forecasting and then 
transmits the forecasting to the corresponding distributors. In an additional aspect, the 
distributors are organized and assigned a local distribution committee based on a location 
thereof. In even another aspect, each local distribution committee includes a network- 
based interface for transmitting the data. 

Figure 115 is a flowchart of a process 11500 for price auditing in a supply chain 
management framework. A network is utilized in operation 11502 to collect data from a 
plurality of stores of a supply chain that relates to the sale of goods by the stores. 
Electronic order forms are generated in operation 11504 based on the data for ordering 
goods from a plurality of distributors of the supply chain and then sent to the distributors 
in operation 11506 utilizing the network. In response, invoices are received from the 
distributors utilizing the network in operation 11508. A price for the goods is then 
calculated utilizing the electronic order forms and the invoices in operation 11510. 
Subsequently, the price is audited in operation 11512. 

In one aspect, the price is audited by comparing the price to a predetermined amount. In 
another aspect, the price of the goods is calculated from the electronic order forms 
utilizing a table mapping a plurality of goods with a plurality of prices. In a further 
aspect, the electronic order forms are generated by the stores. In an additional aspect, the 
electronic order forms are generated by the stores. In yet another aspect, an electronic 
mail alert is generated in response to the audit. 
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Figure 116 is a flowchart of a process 11600 for auditing performance in a supply chain 
framework. Data is collected from a plurality of supply chain participants utilizing a 
network in operation 11602. This data relates to the sale of goods by the supply chain 
participants. Access to the data is allowed utilizing a network-based interface in 
5 operation 11604. Electronic order forms are generated based on the data for a supply 
chain participant in operation 11606. The generated electronic order forms are sent to the 
to the supply chain participant utilizing the network in operation 11608. A performance 
of the delivery of the goods by the supply chain participant is then tracked in operation 
11610. The tracked performance of the delivery of the goods by the supply chain 
10 participant is subsequently audited in operation 1 1612. 

In one aspect, the performance may be audited by comparing the performance to a 
performance indicated on the electronic order forms. In another aspect, the performance 
may indicate a day of the delivery. In a further aspect, the performance may indicate an 
1 5 hour of the delivery. In an additional aspect, the performance may be tracked by entering 
the performance utilizing the network-based interface. In another aspect, an electronic 
mail alert may be generated in response to the audit. 



fj Figure 117 is a flowchart of a process 11700 for providing an electronic mail virtual 

ij 20 private network in a supply chain management framework. Utilizing a network, data is 
J collected in operation 1 1 702 from a plurality of outlets of a supply chain that relates to 

the sale of goods by the outlets. Access to the data is allowed in operation 11704 
utilizing a network-based interface. The data is processed in operation 11706 and then 
sent in operation 11708 using electronic mail via the network to one or more of the 
25 following: a supplier, a distributor and the outlets in the supply chain. 

In one aspect, the network includes the Internet. In another aspect, the processed data is 
sent to the supplier, the distributor, and the outlets. In such an aspect, the supplier, the 
distributor, and the outlets may be registered with a process that includes the collection of 
30 electronic mail addresses thereof. In further aspect, the processed data includes 
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forecasting, promotion planning, and ordering. In an additional aspect, the processed 
data may be sent to a supplier, a distributor, as well as outlets indicated by the data. 

Figure 118 is a flowchart of a process 11800 for secret pricing in a supply chain 
5 management framework. An agreement is negotiated with a supplier of a supply chain 
that sets a first price for a predetermined product in operation 11802. The predetermined 
product is then ordered from the supplier by a purchasing supply chain participant in 
operation 11804. Data is collected from a plurality of supply chain participants utilizing 
a network in operation 11806. The data relates to the sale of goods by the supply chain 
10 participants. An invoice is subsequently received from the supplier by the purchasing 
supply chain participant in operation 11808. This the invoice reflects a second price for 
the predetermined product which is different from the first price. 



In one aspect, the ordering is carried out utilizing a network. In a similar aspect, the 
15 receiving is carried out utilizing a network. In another aspect, the second price is a 

function of the first price. For example, the first price may be a percentage of the second 
price. In further aspect, the second price is converted to the first price prior to 
processing. In such an aspect, the processing may include market analysis. In yet 
another aspect, a supply chain manager may collect from the supplier an amount equal to 



Figure 119 is a flowchart of a process 11900 for managing risk in a supply chain 
management framework. A network is utilized in operation 11902 to receive data from a 
plurality of outlets of a supply chain that relates to an amount of products sold by the 
25 outlets. A maximum acceptable amount of loss is determined in operation 11904 and the 
maximum acceptable amount of loss is translated to acceptable ordering standards in 
operation 11906. An electronic order form is then generated based on the data and the 
acceptable ordering standards for ordering products from a distributor of the supply chain 
in operation 11908. 
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a difference between the second price and the first price. 
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In one aspect, the maximum acceptable amount of loss includes a predetermined amount 
of money. In another aspect, the acceptable ordering standards allow the calculation of a 
maximum amount of products that can be ordered as a function of the data. In a further 
aspect, the acceptable ordering standards allow the calculation of a maximum price of 
5 products that can be ordered as a function of the data. In an additional aspect, the 
translating is carried out utilizing a look-up table. In yet another aspect, an alert is 
generated upon the products ordered based on the data not meeting the acceptable 
ordering standards. 

10 Figure 120 is a flowchart of a process 12000 for product tracking in a supply chain 

management framework. Data is received from a plurality of outlets of a supply chain 
utilizing a network in operation 12002. The received data relates to an amount of 
products sold by the outlets. Electronic order forms are generated based on the data for 
ordering products from a distributor of the supply chain in operation 12004. The 
fl 15 electronic order forms indicate an amount of the products ordered by each outlet An 
amount and a location of the products are tracked utilizing the data and the forms in 
operation 12006. 

In one aspect, the products may be tracked for recall purposes. In another aspect, the 
20 amount and the location of the products may be tracked by subtracting the amount of 
products sold from the amount of products ordered for each of the outlets. In a further 
aspect, the amount and the location of the products may be audited. In an additional 
aspect, the amount of products sold and the amount of products ordered may be 
accessible via a network-based interface. In yet another aspect, the network includes the 
25 Internet. 
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Figure 121 is a flowchart of a process 12100 for auctioning surplus products in a supply 
chain management framework. Utilizing a network, data is received from a plurality of 
outlets of a supply chain in operation 12102. The received data relates to an amount of 
30 products sold by the outlets. The received data is then made accessible to the outlets, 
distributors, and suppliers utilizing a network based interface in operation 12104. 
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Utilizing the network-based interface, surplus products from at least one of the outlets are 
auctioned in operation 12106. 

In one aspect, the outlets, the distributors, and the suppliers may be provided access to the 
5 network-based interface. In such an aspect, the outlets, the distributors, and the suppliers 
may also be capable of submitting bids utilizing the network-based interface. In another 
aspect, the network includes the Internet. In a further aspect, the auctioning may be 
initiated in response to one of the outlets closing. 

1 0 Figure 122 is a flowchart of a process 12200 for managing a supply chain utilizing a 

network. Data is received from a plurality of outlets of a supply chain utilizing a network 
in operation 12202. The received data relates to the sale of products by the outlets. An 
electronic order form is then generated in operation 12204 based on the data for ordering 
products from a distributor of the supply chain. Access to the data is provided in 

1 5 operation 12206 utilizing a network-based interface equipped to handle secure sockets 
layer (SSL) protocol. 

In one aspect, the access may be provided only after verification of a password and a user 
name. In another aspect, the network-based interface may be capable of timing out after 
20 a predetermined amount of time. In a further aspect, the data and electronic order form 
may be encrypted. In yet another aspect, the network includes the Internet. In an 
additional aspect, the outlets, the distributor, and a supplier each may be provided access 
to the network-based interface. 

25 Figure 123 is a flowchart of a process 12300 for managing a supply chain utilizing a 

network. Data from a plurality of outlets of a supply chain is received utilizing a network 
in operation 12302. The received data relates to the sale of products by the outlets. An 
electronic order form is generated in operation 12304 based on the data for ordering 
products from a distributor of the supply chain. Access to the data is allowed utilizing a 

30 network-based interface in operation 12306. 
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In one aspect, forecasting may be made available on the network-based interface. In 
another aspect, promotion planning may be made available on the network-based 
interface. In a further aspect, the network includes the Internet. In an additional aspect, 
the outlets, the distributor, and a supplier may be allowed access to the data. 

5 

Figure 124 is a flowchart of a process 12400 for disseminating calendar information in a 
supply chain utilizing a network. A network is utilized in operation 12402 to receive data 
from a plurality of outlets of a supply chain relating to the sale of products by the outlets. 
A calendar of events is generated in operation 12404. Access to the calendar of events is 
10 allowed utilizing a network-based interface in operation 12406. 

In one aspect, the calendar of events may be generated based at least in part on the data. 
In another aspect, the calendar of events may be generated based at least in part on 
promotion planning. In further aspect, the network includes the Internet. In an additional 
1 5 aspect, the access to the calendar of events may be restricted to only a predetermined set 
of the outlets. In such an aspect, the restricted access may be enforced utilizing 
passwords as a further option. 
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Illustrative Embodiment 



This section illustrates a Supply System according to an exemplary embodiment of the 
present invention. Accordingly, Figure 125 illustrates a graphical user interface 12500 
for generating cost system components. The basic components of the cost system are 
Items 12502, FOB points (Supplier Sites) and Distribution Centers. To add to or modify a 
25 cost system component, the relevant component is selected from the Supply menu. Then 
New 12602 is selected from selection screen 12600. See Figure 126. 

Figure 127 illustrates an Add Items window 12700 displayed upon selecting Items from 
the Supply menu and New from the selection screen. Several fields of the window are: 

30 
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• Item Desc 12702: Enter a uniquely identifying Item description. This is the 
name that will appear on all reports including Landed Cost reports, Price 
Notifications and Contract Exhibits. (The sections entitled Building Cost Matrices 
and Creating Contracts, below, provide an explanation of these reports.) Figure 
128 illustrates a Landed Cost Report 12800 by Distribution Center. 

• Product Cat Code: Product category, for example, dry, refrigerated, frozen etc. 

• Item Rank: Optional, Test, Mandatory or Unknown. 

Note that the underlined data indicates that the information is required. 

Figure 129 illustrates an Item/FOB button 12900 that calls up an FOB window 13000 
(see Figure 130) upon its selection. If FOB points are already in the system, Item / FOB 
associations (Who can supply the product) can be created from this screen. A procedure 
for adding new FOB points is set forth below. 

The information entered for each Item FOB has many implications throughout the 
purchasing automation systems. The values are used on many of the reports provided to 
Suppliers, Distributors and Board Members as well as being an integral part in Bid and 
Least Cost calculations. The following list defines several of the fields of the FOB 
window. Self-explanatory columns are omitted. 

• Supplier Item Desc: Item description by which the Supplier identifies the Item. 
This may not always agree with the Supply Chain coordinator's description and in 
some cases the Supplier may have the same item description for many Supply 
Chain coordinator items, for example, promotional cups. PN (PN - Data is used 
on a Price Notification) 

• Item Size: Used to store case dimensions; can be replaced by case specific 
columns. PN 

• Item No: Suppliers Item number. PN 
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• Case Length, Width, Depth: Product of the columns should equal the 
Item Cube. 

• Tie / High Quantity: Case Width and Height on a pallet, i.e. 3 Cases across on 4 
levels. PN 

5 ♦ Item Cube: Volume per case. PN / BLC (BLC - Data is mandatory to 
complete the Bid / Least Cost calculations.) 

• Cases per Truckload: # cases per truck. PN / BLC 

• Gross Weight: Gross Weight of each case. PN / BLC 

10 The process for adding FOB points is essentially the same as adding Items. In this case, 
Supplier Sites is selected from the Supply System main menu, then New on the selection 
screen. Figure 131 illustrates a window 13100 for adding an FOB point. In the Site 
Name field 13102, the name of the site is entered. One standard naming convention for a 
supplier site is SUPPLIER NAME - CITY, STATE. The Site Role field identifies the 

1 5 role of the site. Only sites that have been marked with a role of "FOB Shipping Point" or 
"Corporate & FOB Point" are available to the purchasing systems when building cost 
matrices, creating Bids, etc. 

The Supplier should be added to the system before identifying the FOB points. In many 
20 cases the Suppliers headquarters is also an FOB point. These records will be identified 
with a site role of "Corporate & FOB Point". See below for a further explanation of Site 
roles. 

Figure 132 depicts a screen 13200 for adding Distribution Centers. Distribution Centers 
25 are added much less frequently and basically have to satisfy the same requirements as 
FOB points. They must have a role of "FOB Shipping Point" or "Corporate & FOB 
Point" and have an "Active" status in order to be selected. 

Figure 133 is a flowchart of a process 13300 for creating cost system components in a 
30 supply chain utilizing a network in accordance with an embodiment of the present 
invention. A plurality of items are defined utilizing a graphical user interface in 
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operation 13302. A supplier site is selected from a set utilizing the graphical user 
interface in operation 13304. The set of supplier sites is determined based on the 
definition of the items. A distribution center is also determined utilizing the graphical 
user interface in operation 13306. The distribution center is designated to interface with 
5 the supplier site for distribution of the items. 

In one aspect of the present invention, the items may be defined utilizing an item 
identifier, a category, and a rank. In another aspect, the set of supplier sites may be 
determined utilizing on an association between the definition of the items and the 
10 supplier sites. In an additional aspect, the set of supplier sites may be capable of 
supplying the defined items. In a further aspect, the supplier sites may be defined 
utilizing a name and a role identifier. In an additional aspect, the items are defined, the 
I supplier site selected, and the distribution center determined utilizing a network. 

h 

Si 

ft 15 Building Cost Matrices 

3 

i| Once the basic components of the cost system have been created, the matrices can either 

n be manually created or can be generated by the Least Cost system after completion of 

^ analysis. (See the section entitled Creating the Cost Matrices, below, for a detailed 

y 20 explanation of this option.) 

■h 

Figure 134 illustrates a matrix window 13400. Matrices can be created from scratch or by 
making a copy of a previous matrix using a New Using Previous option. The important 
options at the top of the matrix window are as follows: 

25 

• Begin: / End: Identifies the starting point and length of the current model. 
Matrices cannot overlap and at the point one attempts to save an overlapping 
matrix, he or she will be prompted to change the dates. 

• Final: Only matrices that have been finalized will appear on all published reports 
30 in the system. Note that even if the dates suggest that this matrix is current, the 

fact that the final indicator is left unchecked will filter it from reports. 
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• Apply By: This feature allows a user to effect a change to one or multiple 
records. For example, say an Items Invoice FOB price will be the same regardless 
of the FOB point. If the price for one FOB point is entered, and "Apply By" 
Supplier is selected, the system would automatically copy the same value to all 
other FOB points belonging to that Supplier. 

Figure 135 illustrates a matrix 13500. Matrices are preferably used to display 
performance metrics in an organized and easily understandable manner. Such 
performance metrics include on time delivery, fill rate, perfect delivery, lead-time, 
payment periods, costs, order charges, etc. 

The primary purpose of a matrix is to identify the source and destination for the product 
in question. In this example, the Ameriserve Denver Distribution Center (DC) will be 
supplied by Tyson's Greenforest, Arkansas FOB point. 

Figure 136 illustrates an FOB matrix 13600. Columns in the matrix are set forth below. 

• Con FOB the Contract FOB is the actual price from the FOB point selected 
on the current record. In the case of volume pricing, this signifies the price at the 
volume breakpoint, based on the total award to this FOB point across all DCs. 

• Inv FOB the Invoice FOB is the weighted average contract FOB for the 
current matrix. Each contract fob price is weighted based on the volume on that 
particular lane. This is the price that the DC will actually receive on their invoice. 
All DCs receive the same invoice price with the exceptions of RDC lanes (See 
below for a more detailed explanation.) 

• Freight Actual freight charge on the lane. 

• Landed the actual cost to the Distribution Center. 

Figure 137 illustrates a contract matrix 13700 displayed upon selection of the Contract 
button 13800 shown in Figure 138. 
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• Contr The contract that covers this item and date range. (See the section 
entitled Creating Contracts for a detailed explanation.) The contract is associated 
with the Matrix by selecting the Contract Link option on the toolbar. 

• LB The total weight of product (generally only for beef) on this lane. 

• Trk The number of trucks that the weight entered represents. 

• Routing The routing option used on this lane. Either Full Truckload (TL), 
Less than Truckload (LTL), Re-distribution (RDC) or Truckload with a minimum 
(TLMIN). The section entitled Optimal Product Routing provides a detailed 
description with examples of each routing type. 

Figure 139 depicts a minimum order matrix 13900. Matrix items include: 

• Min Ordr / UM When the usage on a lane suggests that the DC will not 
order full truckloads, the minimum order for TLMIN orders can be specified 
using these columns. 

• Slip Whether the product ships on Slipsheets or Pallets. 

• Deliv. In certain cases the Suppliers will quote only a price directly to the 
Distribution Center. In these scenarios the Invoice FOB, Contract FOB, Freight 
and Landed columns will be blank and the delivered price is entered here. 

Figure 140 illustrates a shipping matrix 14000. 

• Carrier Rail, Truck, Ship etc. The method of shipment. 

• Stated Vol the expected volume on the lane. This number will show up on the 
contract reports discussed in the next section. 

Once the matrix is complete, it should be finalized and saved. 

At this point the Distribution Center (DC) Price notification can be generated. This 
communicates to the DCs their FOB points selected and relevant pricing, and is 
generated by selecting the Price Notification option from the Options menu 14100 
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(Figure 141) or the Notification toolbar button 14200 (Figure 142). Supplier 
confirmation is provided with the contract for all items except Beef 

For example, since beef pricing is changed much more frequently than other products, 
their contracts cover multiple cost matrices. They have a separate DC Notification and 
Supplier Confirmation report, which is only enabled when working with beef items. 

The beef reports are generated in letter format and automatically combine all beef items 
into the same report. 

Figure 143 illustrates selection of a Multi-Item Price Notification 14300. If a Price 
Notification is generated from the cost matrix window, it will only include the current 
item. Also provided can be the facility to generate multi-item price notifications. The 
windows standard paradigm of CTRL+CLICK and SHIFT+CLICK can be used to select 
multiple items on the item selection window. The report will automatically combine all 
selected items in one report, but may or may not be possible to select two matrices for the 
same item. 

Figure 144 is a flowchart of a process 14400 for utilizing cost models in a supply chain 
utilizing a network in accordance with an embodiment of the present invention. At least 
one item to be distributed is identified utilizing a graphical user interface in operation 
14402. A cost model is associated with the item utilizing the graphical user interface in 
operation 14404. The graphical user interface is then utilized to determine a time frame 
during which the cost model is valid in operation 14406. The cost model identifies a 
contract cost, an invoice cost, and a landed cost associated with the distribution of the 
item. 

In one embodiment of the present invention, reports for each of the items may be 
generated utilizing the cost model. As a further aspect, at least one of the reports may be 
for a plurality of the items. In one aspect, the cost model identifies a source and a 
destination of the item. In another aspect, a plurality of the cost models may be available 
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for being associated with the item. In a further aspect, the item may be identified and the 
cost model associated with the item utilizing a network. 

Creating Contracts 

The Price Notification reports, discussed in the previous section provide the 
communication link with the DCs, whereas the Supplier reports are generated within the 
contracts system. 

In order to link contracts to cost matrices as discussed in the previous section, the 
relevant items must first be associated with the contract. An item selection screen is 
accessed such as by selecting a New Item button 14500 as shown in Figure 145. The 
item selection screen works in the same manner as the selection screens discussed in the 
section on "Creating Cost Components". 

Preferably, Item / Contract associations cannot overlap; in other words there cannot be 
two contracts for the same items with a Supplier at the same time. The system will 
automatically prevent creation of this situation. 

Figure 146 illustrates a Contract/Buyer association screen 14600. 

• Contract ID: The contract number is assigned automatically by the system once 
the user saves for the first time. 

• Current Buyer: Products frequently change hands as buyer responsibility's 
change. The present invention provides the ability to select the current buyer to 
accommodate this fact. 

Figure 147 depicts a contract schedule screen 14700; Pertinent fields are: 

• Contract Start / End: Contracts can span multiple matrices, but cannot 
overlap. The dates will appear on all reports sent to the Supplier. 
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• Effective: Either shipment or order date. 

• Payment Terms: Terms of payment. 
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Lead-time, Effective and Payment Terms all appear on the DC Price notification. 

The present invention also generates several reports. A Generate button 14800, shown in 
Figure 148, links to Microsoft Word and populates required fields with the contract 
information. Once created, a contract cannot be overwritten by the system. Further, 
contracts can only be removed by an administrative department. 

Figure 149 illustrates an Exhibit A button 14900, which upon selection provides the 
Supplier with the "Approved Products" listing for the current contract. This identifies the 
products and FOB points for which the contract is being established. 



1 5 The Exhibit A report shows all detail added when the Item / FOB records is created. It is 
important in that it identifies the relationship between the Supply Chain Coordinator's 
item and the Supplier's item and also ensures that the information in the system is current 
and correct. 



20 Figure 150 illustrates an Exhibit B button 15000, which upon selection provides the detail 
M on per case pricing and volume for each lane assigned to this Supplier. 

The Exhibit B always retrieves the latest finalized matrix for each item. If the contract 
has not been linked or the relevant matrix finalized, they should be done prior to 
25 generating this report. 

In most cases, the contract term will correspond to the start and end dates of the linked 
matrix. However, if the contract will outlast the matrix, the screen 15100 of Figure 151 
is presented. The various columns include: 

30 
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• Cost Matrix End Date identifies the minimum term but will also mean that at the 
end of the matrix the contracted pricing will expire and a new Exhibit B should be 
generated and signed. (See Replacement Exhibit B) 

• Contract End Date assumes that the pricing will not change for the length of 
the contract although the matrix suggests that this may not be true. 

• No End date essentially leaves it open-ended. 

Since the Exhibit B will publish the term of the pricing, the choice of end date becomes 
very important. 

In some cases, there may be a need to publish new pricing and volumes during the term 
of the contract. Selection of the Replacement Exhibit B menu item 15200 accommodates 
this process. See Figure 152. The replacement Exhibit B differs from the standard 
Exhibit B only in that it provides a section at the end of the report for signatures. 

Exhibit C, generated upon selecting the Exhibit C button 15300 of Figure 153, lists 
product routing for each lane and any minimum order quantities if applicable, whether 
the product is sent in full truckloads, full truckloads with a minimum order quantity, less 
than truckload or for re-distribution. 



Figure 154 is a flowchart of a process 15400 for creating a contract utilizing a supply 
chain graphical user interface in accordance with an embodiment of the present 
invention. A contract is identified utilizing a graphical user interface in operation 15402. 
The contract is the associated with an item to be distributed utilizing the graphical user 
25 interface in operation 15404. The item is also prevented from being associated with more 
than one contract in operation 15406. 

In one aspect of the present invention, the contract may be identified utilizing a start date, 
an end date, an execution date, and payment terms. In one embodiment, the contract may 
30 be generated by populating a template with information associated with the contract. In 
another aspect, items capable of being associated with the contract are displayed. In a 
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further aspect, the contract may be identified and the contract associated with the item 
utilizing a network. In such an aspect, the network may include the Internet. 

Bid Proposal Processing 

5 

The proposal system has been designed to allow quick and easy creation of a generic 
proposal for any item(s) and supplier(s) within the Supply System. By centralizing the 
creation and storage of the data, an online record of all current and historical proposals is 
enabled. The proposal system is also tightly integrated with the Least Cost analysis 
10 system. 

The system is made up of two modules: data entry and reporting. 

Data Entry allows a user to enter or select all information for generating a complete 
1 5 proposal. Data Entry includes entering general proposal information (i.e. proposal name, 
buyer name, due date, contract begin date and end date), items, suppliers, restaurants 
served, usage information, selecting cost component templates, and updating Microsoft 
Word template documents. Most of the information above will be generated from data 
within the Supply System, but the system will allow the user to change some information 
20 when necessary. 

Reporting: After data has been entered, the proposal can be generated and printed. In the 
reporting module of the proposal process, a user can update specific documents for a 
supplier, print any of the reports included in the proposal, and/or generate the entire 
25 proposal. 

By following the flow of the tabs on the proposal window d2900 (see Figure d29), the 
user will be guided through the proposal process. When enough data is entered to 
continue on to the next step in the proposal process more tabs will be enabled. For 
30 example, when the user has completed entering information on the Main Info tab, the 
Items, Suppliers, DCs, and FOB Price tabs will become enabled. 
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The goal of the proposal system is to provide a way to generate a proposal in a more time 
efficient manner while at the same time centralizing the storage of proposals and 
allowing integration of the proposal with the Least Cost Analysis system. 

5 

A new Proposal can be created in either of two ways. The first and probably the most 
simple method is to build the proposal from scratch. Referring to Figure 155, to create a 
proposal from scratch, select Proposal from the Supply menu. Then select Edit/New 
15500 to open an existing Proposal or create a new proposal. After selecting the 
1 0 Edit/New menu option, the standard query screen is presented. Select New on the 
standard query screen to begin generating the proposal. 

The second method uses the "New Using Previous" feature of the present invention, 
which will create an entire copy of a previous proposal (not including any documents) 
1 5 and allow the user to make any necessary modifications. To being the process, select the 
New Using Previous menu item 15502 to copy an existing Proposal into a new Proposal. 
Note that this feature is similar to the Cost Matrix feature of the same name. 

Figure 156 illustrates a Bid Proposal Window 15600.. The Bid Proposal window is made 
20 up of several different 'tabs'. These tabs are identified by the labels across the top of the 
window. Examples of the tabs are 'View Bid' 15602, 'Items' 15604, and 'Usage' 15606. 

The first tab visible on the Bid Proposal window when it is opened is the 'Main Info' tab 
15608. The 'Main Info' tab is where general information for this proposal is entered. The 
25 main info tab on the Bid Proposal window shows general information, comments, and 
dates associated with this bid. Such information includes: 

• Proposal ID: Unique identifier for this proposal. Generated by the Supply 
System, Noneditable, used for identification on specific reports and for retrieval 
30 of proposals. 
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Proposal Name: Unique name for this proposal. It should be representative 
of the type of proposal the user is completing, and will be the primary method of 
identifying and retrieving the proposal later. 

Buyer Name: Name of buyer creating this proposal. Used to retrieve proposals 
by buyer. 

Proposal Due Date: Date that this proposal is due back to the Supply Chain 
Coordinator. Used on the proposal Cover Letter report. 
Contract Begin Date: Date that contract associated with this proposal begins. 
Used on the proposal Cover Letter report, and used to determine contract length 
for usage calculations. 

Contract End Date: Date that contract associated with this proposal ends. Used 
on the proposal Cover Letter report, and used to determine the contract length for 
usage calculations. 

Actions: Actions are comments or activities associated with this proposal. A 
proposal can have an unlimited number of actions as long as each action has a 
date and text. To add, delete, or print actions use the buttons on the window's 
toolbar 15700, shown in Figure 157. 

i 

'4 After entering all of the information on the 'Main Info' tab the user can move to the next 

| 20 tabs, 'Items', 'Suppliers', and 'DCs'. These tabs are where the creation of a proposal 

^ begins. Although these elements are added on three separate tabs in this description, the 

methods used to include them are consistent. 

Figure 158 illustrates the page 15800 under the Items tab. As shown, the left side of the 
25 page under each tab is the search and selection area. It functions in the same manner as 
the rest of the Supply System, in that the user enters a search string and clicks search, and 
similar names to the search string will be retrieved. For example, as shown in Figure 159 
which illustrates the page 15900 under the Items tab upon selection of the Search button, 
all Items beginning with "CUP-HOT" would be retrieved. After clicking on the 'Search' 
30 button, the present invention shows a list of Items matching 'CUP-HOT\ 
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These tabs are "Drag and Drop" enabled; the user can select any of the items found and 
by clicking on the relevant item and dragging it to the right, it is now included in the 
analysis. By the same token, dragging the selected item to the left will remove it from the 
proposal. The buttons between the search and selected areas can also can move the 
5 selections. Button 15902 moves whatever has been highlighted on the left and includes it 
in the proposal. Button 15904 moves all items retrieved and includes them in the 
proposal Button 15906 removes everything previously included in the proposal. Button 
15908 removes only the highlighted selections from the proposal. Further, multi-select 
using CTRL+Click, and double clicking on any Item to move it are preferably also 
10 supported. 

After a search for the desired item(s) has been performed, another search can be 
performed by clicking the * Query' button and entering new search criteria. 



15 It is important to note that in order to include any of the elements in the proposal, they 

''"4 

must have previously been entered in the Supply System. The Supplier selection tab 
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retrieves all active and un-approved Suppliers that match the search criteria and have at 
least one active contact. Inactive elements should not appear as a relevant selection in 
any of the tabs. 

Since the DCs are generally consistent between proposals, a complete list of all active 
DCs is retrieved and then the user simply selects the relevant one, or in most cases 
presses the button to move them all to the right. 



25 When the user leaves any of the tabs for the first time, the new elements are propagated to 
all dependent tabs. For example, if a new Item is added, that implies new usage 
information. 

Figure 160 illustrates a page 16000 under the FOB Price tab for selecting FOB price 
30 component worksheets. As part of the proposal process Suppliers are asked to bid on 

FOB prices. The worksheets that are provided to the suppliers can vary depending on the 
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type of items included in the bid. There are several template FOB Price component 
worksheets in the system. A different worksheet may be associated to each item. For 
example, if a proposal involving mayonnaise were being prepared, the user would select 
the 'Mayonnaise Component' worksheet as shown in Figure 160. 

An association between a worksheet and each item must be generated before continuing 
to the next tab. Once all FOB price components are selected, the remaining tabs are 
enabled. 

The selected worksheets can be printed along with the bid and can be viewed on the 
Template' tab. For more information on the 'FOB Price Component Worksheet' see the 
Reporting section of this document. 

The Proposal mechanism for estimating usage functions in almost exactly the same 
manner as in the Least Cost Analysis System. It is comprised of two tabs; the DC/Rest 
tab is used for estimating restaurant growth by DC, and the Usage tab to estimate same 
store or item growth. The values from the first tab are used in the Usage tab to determine 
the projected usage. For more information on general processing in these tabs see the 
section entitled Distribution Center Usage. 

Figure 161 depicts a window 16100 for managing Distribution Center usage. Although 
the use of the DC/Rest and Usage tabs are almost identical there are a few differences and 
should be pointed out. Also, the tabs may look the same but the data stored here are used 
for different purposes in each process. The differences in the proposal system are 
explained below. Usage information, Gross Weight and Item Cube can be used to 
determine if LTL sheets are printed and/or RDC's are included. 

• Gross Weight the approximate gross case weight of each item. * 

• Item Cube the approximate case volume of each item. 

• Projected Usage Projected usage for the proposal contract period. 
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For example, if the two (2) week truckload weight estimate (two week usage x gross 
weight) is less than the system weight default (48,000 LBS) OR the two week volume 
estimate (two week usage x item cube) is less than system cube default (3000 CFT) for 
any DC, an LTL worksheet is generated and RDC records will appear on the Truckload 

5 Freight Worksheet. The exact gross weight and cube will be requested on the Item 

Worksheet. Realize that the total gross weight for a truck is 45,000 lbs. LTL rates can be 
requested for any lane with less than 48,000 lbs. to avoid having to go back to the 
Supplier for additional rates. Optimal Product Routing in this example uses 43,500 lbs. 
gross weight of product, which accounts for pallet weight. For a detailed look at the 

1 0 components and processing of the Usage Estimator, see the section of the same name. 

Figure 162 is a flowchart of a process 16200 for creating a bid proposal utilizing a supply 
chain graphical user interface in accordance with an embodiment of the present 
invention. A graphical user interface is displayed in response to a request to create a bid 
1 5 proposal in operation 16202. Utilizing the graphical user interface, information is 
received in operation 16204 so that a bid proposal can then be generated using the 
information in operation 16206. The received information may include a buyer name, a 
due date, a contract begin date, and/or a contract end date. 



20 In one aspect of the present invention, the bid proposal may be generated utilizing 
templates. In another aspect, the information may be selected from a displayed list of 
available information. In a further aspect, items capable of being associated with the bid 
proposal may also be displayed. In such an aspect, the information may further include 
usage information associated with the items. In an additional aspect, the information may 

25 be received utilizing a network. 

Proposal Reporting 

In order to create a proposal, the user first edits template documents and then selects 
30 which reports will be included in the proposal. Figure 163 illustrates a Templates button 
16300 which calls the Template window 16400 shown in Figure 164. 
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The Proposal consists of two types of reports, Microsoft Word and Coordinator Supply. 
Microsoft Word reports are formatted and some are editable within Word whereas the 
Supply System reports are generated by the Supply System but are not editable. The 
5 following is a list of reports available in the Proposal System and how they are generated. 

The proposal system allows editing of a Microsoft Word template document which is 
then used to create the actual document that will be included in the proposal. Figure 165 
illustrates a window 16500 displayed upon selection of the Templates tab. A drop down 
10 list box 16502 shows which template documents can be edited. As shown in Figure 165, 
the available templates include the Cover Letter and Price Component Worksheet. To 
start Microsoft Word and edit the selected template, the user double clicks on the 
document in the window. 

1 5 Once Microsoft Word has started the user can edit the template document to fit his or her 
needs. The proposal Cover Letter will be used herein as an example in order to 
demonstrate how to use the template documents. The template bid cover letter is the basic 
cover letter used to create supplier-specific cover letters. 

20 Only generic changes that apply to all suppliers should be made in the template. When 
the proposal is created, this document will be copied to all the suppliers and contacts 
associated with this proposal. The user will be able to edit a supplier specific cover letter 
later in the proposal process. 

25 When editing of the cover letter ahs been completed, the document is saved by selecting 
File, Update from Microsoft Word's menus 16600, as shown in Figure 166. Now the 
user may return to the Supply System and continue with the proposal process. 

Select Update to update the template 
30 After the user has completed editing the templates, the proposal can be created. 
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Before creating the proposal, the user is allowed to select which reports should be 
included. Figure 167 is an illustration of the page 16700 presented upon selection of the 
Create Bid tab. To design/customize the appropriate proposal and select reports, the user 
checks or unchecks the appropriate boxes. When the user is satisfied with the selections 
5 click the 'Create Bid' button 16800 on the toolbar. See Figure 168. 

The present invention then creates all of the documents needed to print this proposal. The 
user can view any of these reports by making the appropriate selections in the drop down 
list boxes 16900 shown in Figure 169. The user also has ability to view any of the 
10 proposal reports one at a time and for any specific supplier. 

Printing 

t The proposal system allows a certain degree of flexibility when it comes to printing the 

=Q proposal. The user can either print out one report for a specific supplier (the currently 

ft 15 selected report shown on the window) or print the entire proposal. When printing the 

| entire proposal, the documents will be collated by supplier. Microsoft Word documents 

1| will be printed first for all suppliers followed by the Coordinator generated reports. The 

>l different printing mechanisms can be controlled by the buttons on the toolbar, shown in 

$ Figures 170 and 171 . For example, the Print button 17000 Prints the currently selected 

, ij 20 report on the window. The Print Bid button 1 71 00 prints the entire proposal. 

i «<? 

i ;j| 

This will print all of the reports that have been checked off on the Create Bid tab, only 
choose this option if the user is sure that he or she is ready to print the entire proposal. 
The proposal is now ready to be sent out. When proposals are returned, the information 
25 can now easily be moved from the proposal process into the Least Cost Analysis. 

Figure 172 is a flowchart of a process 17200 for proposal reporting utilizing a supply 
chain graphical user interface in accordance with an embodiment of the present 
invention. A proposal is identified in operation 17202 utilizing a graphical user interface. 
30 A plurality of components of the proposal are then indicated utilizing the graphical user 
interface in operation 17204. The selection of the components is subsequently allowed 
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utilizing the graphical user interface in operation 17206 so that a proposal can be created 
utilizing the selected components in operation 17208. 



In one aspect of the present invention, the proposal may be generated utilizing templates. 
5 In another aspect, the graphical user interface may be displayed utilizing a network 
browser. In a further aspect, the proposal may be editable. In an additional aspect, the 
proposal may be read-only. In yet another aspect, the proposal may include a bid 
proposal for goods to be shipped from a supplier to an outlet. 

1 0 Creating a New Analysis 

A Least Cost Analysis can be created in either of three ways. The first and probably the 
most cumbersome method requires building the analysis from scratch. The second 
method integrates the Bid proposal selections and creates the basis for a new analysis. 
15 Finally, the "New Using Previous" feature can be used, which will create an entire copy 
of a previous analysis version and allow the user to make any necessary modifications. 

After selecting the Least Cost Toolbar button 17300 (see Figure 173), the user is 
prompted with the standard query screen 17400, shown in Figure 175. The New button is 
20 selected. The details of the actual Analysis features are covered in a section below. 

The New Using Previous option is selected from the menu 17500 shown in Figure 175. 
Similar to the Cost Matrix feature of the same name, the user can make a complete copy 
of a previous Analysis version. However, unlike the Cost system there is no requirement 
25 that Analysis' dates cannot overlap. 

Referring to the Bid Integration feature, since a lot of the information selected by the user 
in the Bid Proposal is also relevant to a Least Cost Analysis, the present invention 
provides the ability to integrate the Bid information in the analysis. 

30 
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To use the Bid Integration feature, the user selects the New option as above and the first 
column on the Analysis Tab will provide an alphabetical list of all Bid Proposals in the 
system. This will copy the Items, Distribution Centers, DC Usage and usage related 
information such as same store and restaurant growth estimates from the Bid. The user 
5 can change the Bid selection or remove it by selecting "(None)" from the drop down list 
box 17600 shown in Figure 176. 

Figure 1 77 is a flowchart of a process 1 7700 for analysis creation utilizing a supply chain 
graphical user interface in accordance with an embodiment of the present invention. A 
1 0 graphical user interface is utilized in operation 1 7702 to select between a plurality of 

options with each option corresponding to a separate technique of creating an analysis. A 
new analysis is generated upon the selection of a first of the options in operation 17704. 
I Upon the selection of a second of the options, a previous analysis is edited in operation 

: M 17706. Also, upon the selection of a third of the options, a bid proposal is integrated with 

■•k 

: f| 15 an integrated analysis in operation 17708. 

M In one aspect of the present invention, the selection may be received utilizing a network. 

% In such an aspect, the network may include the Internet. In another aspect, the analysis 

;!1 may be a least cost analysis. In a further aspect, the analysis may be capable of being 

$ 

, 4 20 accessed via a network-based interface. 

■■k 

Analysis Tab & Version Control 

Figure 178 illustrates a window 17800 displayed upon beginning an analysis. The 
25 information displayed in the window includes: 

• Analysis Name: The name mat identifies the analysis in the system. 

• Analysis ID: Unique identifier assigned by the system. 

• Buyer: The buyer responsible for this analysis. 

30 • Period of Agreement: The dates that cover the range of the analysis. The dates are 
used to calculate usage estimates if required, and ultimately to create the Cost Matrix. 
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• Unit of Measure 



The units that pricing, plant capacities etc., will be entered. 



Figure 179 depicts an option selection window 17900. Each of the following options can be 
changed by analysis version: 

• Version Name: The name that uniquely identifies each run of the analysis. 
Version Control is handled in more detail later in this section. 

• . .max # of FOBs. . : By changing this option, either a single source (One FOB per 
DC) or a multi-source problem is run. Everything other than "One FOB" is 
considered multi-source with available selections from two to five FOBs and 
unlimited. 

• ..pricing method..: The present invention supports three types of pricing, FOB, 
FOB + Freight and Delivered. Each version can have a different pricing method. 
Pricing is covered in detail in the section entitled Pricing. 

• . .Upcharge(Downcharge).. : Any adjustment positive or negative that should be 
made to the Invoice FOB calculated by the system. 

• ..RDC Truckload Validation..: Ignores the fact that the total usage on winning OPR 
lanes for an FOB may not be enough to warrant RDC routing. 

• Solution Strategy For very difficult problems,, the present invention provides an 
alternate strategy which a user can choose to determine the least cost. Generally, for 
problems that are taking fifteen minutes or more, this strategy is recommended. It 
will arrive at the same answer as the standard strategy but in a much shorter time. 
Since most of the solutions determined by the solver are returned in seconds the 
"Cuts" strategy would actually add unnecessary overhead for simple problems. 

When the analysis tab is selected, the version button 18000, shown in Figure 180, is 
displayed on the toolbar. Unlimited versions of an analysis can be created simply by 
pressing the button. Figure 181 illustrates a verification window 18100 that appears upon 
selection of the version button. 
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The name assigned to the new version should be representative of the variance being 
tested in order to easily differentiate between versions later. A discussion of the methods 
provided for completing version comparisons is presented in the section entitled Solving 
and reviewing the Solution. 
5 ' . 

Items, FOB, DCs and Usage information are not considered to be version dependent, and 
hence this information cannot be changed once a second version of an Analysis has been 
created. However, a variety of methods of excluding this information from consideration 
between versions is provided by the present invention. 

10 

Figure 182 is a flowchart of a process 18200 for analysis version control in a supply 
chain management framework in accordance with an embodiment of the present 
invention. A plurality of separate versions of an analysis are maintained in a database in 
operation 18202. A request for an additional version of the analysis is received utilizing 
15 a graphical user interface in operation 18204. In response to the request, the additional 
version of the analysis is generated in operation 18206. A plurality of parameters of the 
additional version are allowed to be changed utilizing the graphical user interface in 
operation 18208. The parameters that are allowed to be changed include: a maximum 
number of supplier sources, a pricing method, and/or an invoice adjustment. 

20 

In one aspect of the present invention, the additional version of the analysis may be 
named in accordance with a variance associated with the additional version. In another 
aspect, the request may include the selection of an icon on the graphical user interface. In 
a further aspect, the analysis may be a least cost analysis. In an additional aspect, the 
25 request may be received utilizing a network. In yet another aspect, the parameters of the 
additional version may be capable of being changed utilizing a plurality of fields on the 
graphical user interface. 

Adding Items, FOBs and DCs 

30 
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Although Items, FOBs and DCs are added on three separate tabs in the Analysis, the 
methods used to include them are consistent. Figure 183 depicts a tab page 18300 for 
adding and removing FOBs from an analysis. 

5 The left side of each tab is the search and selection area. It functions in the same manner 
as the rest of the system, in that a search string is entered and a search button is selected, 
and similar names to the search string will be retrieved. For example, in the case shown 
in Figure d53, all FOBs beginning with "DOP" would be retrieved. 

10 These tabs are "Drag and Drop" enabled, allowing selection of any of the matches found 
and by clicking on the relevant match and dragging it to the right, it is now included in 
the analysis. The buttons 18302 between the search and selected areas can also move the 
selections, similar to the manner discussed above with reference to Figure 183. Multi- 
select using CTRL+CLICK and double clicking on any Item to move it, are also 

15 supported. It is important to note that in order to include any of the elements in the 
analysis, they must have previously been added to the system. 

The FOB selection tab retrieves all active and un-approved FOBs that match the search 
criteria. Inactive elements will never appear as a relevant selection in any of the tabs. 

20 

Since the DCs are generally consistent between each analysis, a complete list of all active 
DCs is retrieved by default and the user selects the relevant DCs or in most cases presses 
the button to move them to the right. 

25 As shown in Figure 184, which illustrates a portion of the Item tab page 18400, the Item 
tab has an additional editable column 18402 for the Item conversion factor. 

• Conv. Factor: If the analysis is using units other than cases, the present invention 
converts any input data to the relevant lowest common denominator. For 
30 example, if pounds are being used and there were 36 lbs. of a product in a case, 
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the conversion factor would be 36. The default is always one (1), since the large 
majority of analyses will be in cases. 



When leaving either of the tabs for the first time, the system propagates the new elements 
5 to all dependent tabs. For example, if a new FOB is added, that implies new pricing, 
lanes, capacity etc. will also be added and the relevant tabs for each information group 
are updated. 

Figure 185 is a flowchart of a process 18500 for editing supplier information in a supply 
10 chain management framework in accordance with an embodiment of the present 

invention. A graphical user interface is displayed that indicates a plurality of items in 
operation 18502. The selection of one of the items is allowed utilizing the graphical user 
interface in operation 18504. In response to the selection, a supplier associated with the 
item is depicted in operation 18506. A plurality of parameters of the supplier are also 
15 allowed to be changed in operation 18508 utilizing the graphical user interface. 

In one aspect of the present invention, the selected parameters may include a case cube, 
cases per truckload, and/or a gross weight. In another aspect, the changes to the 
parameters may be updated in a database. In such an aspect, the changes to the 
20 parameters may be updated utilizing a network. In one aspect, the network may include 
the Internet. Additionally, the changes to the parameters may be updated in response to 
the selection of an icon of the graphical user interface. 



Item FOB Information 

25 

Figure 186 illustrates a page 18600 that is displayed upon selection of the Item/FOB tab. 
As part of the Bid proposal process, the information that has been entered for each Item 
FOB combination in the system is provided to the Suppliers for correction and/or 
additions. The Item/FOB tab in the analysis is provided for entry of any changes that 
30 they may have made. Even if the analysis is not based on a Bid, some of the information 
on this tab is crucial to the solver process. 
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• Case Cube: the actual case cube or volume. It is used in the calculation of the 
per case two week cube on a lane (item cube x two week usage), which is 
required both by the optimal product routing (OPR) process and in determining 
which lanes have potential for LTL or RDC shipments. A detailed explanation of 
OPR process is provided in the section entitled Optimal Product Routing, below. 

• Cases per Truckload: All freight rates requested by the Bid are truckload rates. 
Since the majority of analyses are performed in cases, cases per truckload may be 
used to determine the case freight. 

• Gross Weight: the actual gross case weight. It is used in the calculation of the per 
pound two week usage on a lane (gross weight x two week usage), which is 
required both by the optimal product routing (OPR) process and in determining 
which lanes have potential for LTL or RDC shipments. A detailed explanation of 
OPR process is provided in the section entitled Optimal Product Routing, below. 

The remaining information is also important, however it is not a factor in determining a 
Least Cost solution. It is stored separately from the Item / FOB Cost information so that 
cases per truckload or case weights can be used without effecting the data that is 
currently considered production. 

At the point, the analysis has been completed and a version that will become the 
production model has been selected. The Cost information is updated by selecting the 
Update button 18700 on the toolbar. See Figure 187. 

Select the Update button and the present invention creates any Item FOB combinations 
that do not exist in the Cost system and update any existing combinations with the 
information the user may have entered to complete the analysis. 

Figure 188 is a flowchart of a process 18800 for adding components in a supply chain 
management analysis in accordance with an embodiment of the present invention. A 
query is entered in a search field of a graphical user interface for searching for a plurality 
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of supply chain components in operation 18802. Results of the search are listed in a 
results field of the graphical user interface in operation 18804. The results are then 
selected from the results field for inclusion in a supply chain analysis in operation 18806. 
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5 In one aspect of the present invention, the selected supply chain components may include 
supplier sites, distributor sites, and/or items. In another aspect, the results may be 
selected for inclusion in the supply chain analysis utilizing icons. In such an aspect, the 
results may also be selected one at a time for inclusion in the supply chain analysis 
utilizing a first icon. The results may also be selected all at once for inclusion in the 
10 supply chain analysis utilizing a second icon. In a further aspect, the supply chain 
components may include items while the graphical user interface includes a field for 
entry of a conversion factor. In an additional aspect, the results may be selected for 
inclusion in the supply chain analysis utilizing a drag and drop feature. 

1 5 Capacity & Excluding FOBs 

The system supports capacity constraints at two levels. Both FOB minimum 
requirements and capacities can be set. They can also be set at the Supplier level. 

20 Figure 189 is an illustration of an exemplary analysis window 18900 displayed upon 

selecting a Capacity tab. For example, in this analysis, two levels of capacity constraints 
have been added for Lamb-Weston Inc. As a Supplier, Lamb must get at least 200 
million pounds of product independent of any further requirement at the FOB level. Both 
the Pacso, WA and American Fall, ID FOB points have minimum requirements of 90 

25 million and maximum capacities of 1 10 million. The remaining FOB in Richland, WA 
has essentially no minimum, but a 55 million capacity. Although the sum of the plant 
minimums is less than the Supplier minimum, the solver will allocate business to match 
the Supplier constraint while still ensuring that each FOB constraint is matched. 
Naturally, the sum of the plant maximums cannot be less than a Supplier minimum. 

30 
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As mentioned above, once a second version of an analysis has been created, it is not 
possible to remove Items, FOBs or DCs. However, a Supplier or individual FOB points 
can be excluded on the Capacity tab. 

Figure 190 illustrates another analysis window 19000. In this example, two of McCain 
Foods FOB points have been excluded from this version of the analysis. The solver will 
not be passed the FOB points or any related information such as lanes, pricing etc. If the 
"Include" has been changed to "no" at the Supplier level, all the FOB points would be 
automatically excluded. 

Figure 191 is a flowchart of a process 19100 for managing supplier sites in a supply chain 
management framework in accordance with an embodiment of the present invention. A 
plurality of supplier sites are displayed utilizing a graphical user interface in operation 
19102. A minimum value and a maximum value of capacity levels associated with the 
supplier sites are determined utilizing the graphical user interface in operation 19104. 
The supplier sites are conditionally excluded from a supply chain analysis utilizing the 
graphical user interface in operation 19106. 

In one aspect of the present invention, terms of a contract associated with the supplier 
sites may also be identified utilizing the graphical user interface. In another aspect, the 
supplier sites may be conditionally excluded utilizing a toggle button. In a further aspect, 
the supplier sites may be conditionally excluded separately for different versions. In an 
additional aspect, the minimum value and the maximum value of the capacity levels may 
be determined utilizing a network. In such an aspect, the minimum value and the 
maximum value of the capacity levels may also be determined utilizing TCP/IP protocol. 

Pricing 

On the analysis tab, the option of selecting the pricing method being for this analysis 
version is presented. Depending on the selection previously made, the Price tab will be 
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used for FOB or FOB & Freight pricing or the Price Dlvd tab for delivered pricing. The 
present invention also provides the ability to factor volume pricing into the analysis. 

Figure 192 is a depiction of an FOB pricing window 19200. In the simplest of cases, a 
price (Contract FOB) will have been negotiated for each Item and FOB combination in 
the analysis. Since the solver is passed a basket (weighted average across all items in the 
analysis) price for each lane, no price field can be left blank. In the example shown in 
Figure 192, bulk mayonnaise has a price of $8.42 from the Hudson Industries Troy, Al 
plant and bulk tartar sauce is priced at $9.23. 

Two forms of volume based pricing are supported in the Least Cost system: Supplier 
volume and FOB volume. They are mutually exclusive in that by version there can be 
only one type of pricing. 

1 5 Figure 193 depicts an illustrative FOB Volume Pricing screen 19300. In this example, 
American Food Service offers two volume pricing discounts at their FOB point. Any 
volume awarded to them from 0 to 2,090,000 pounds has a price of $ 1 .0026/pound. If 
they are awarded volume between 2,090,000 and 2,508,000 that price drops for all 
volume to $1.0016/pound. For any volume over 2,508,000 pounds the price drops to 

20 $1 .0010/pound. As the solver is deciding the optimal distribution model, if their FOB is 
awarded volume over any of the breakpoints it will grab the lower price and keep solving 
until the least cost is determined. The new price applies to all volume awarded from that 
FOB point. 

25 In many cases the Suppliers may not be as concerned about the volume awarded to each 
individual FOB point as to the overall volume awarded across all their FOB points. 

Figure 194 depicts a Supplier Volume Pricing window 19400. In the pricing scheme 
shown in Figure 194, Ventura has negotiated a Supplier volume pricing breakpoint. For 
30 any volume awarded between 0 and 999,999 cases the price for bulk mayonnaise will be 
$8.94 and $9.51/case for bulk tartar from Chambersburg and $9.12 and $9.58/case from 
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City of Industry. If the combined volume across both of their FOB points exceeds 
100,000 cases, the price drops to $8.84 and $9.41/case from Chambersburg and $9.02 and 
$9.48 from City of Industry. This price reduction is independent of the allocation to 
either FOB point as long as the overall award exceeds the Supplier volume breakpoint. 
5 The new price applies to all volume awarded. 

It is also possible to have the new solver determine the Least Cost when the pricing is 
quoted on a delivered basis. Once a pricing method of "Delivered" is selected on the 
analysis tab the Price Dlvd tab is enabled. Figure 195 shows a Delivered Pricing screen 
10 19500. 

Pricing is entered in the same manner as FOB pricing, and as in FOB pricing, the user 
must provide a price for all Items on a lane if at least one price is entered. Lanes can be 
excluded simply by providing no prices for those lanes. 

15 

Figure 196 is a flowchart of a process 19600 for pricing in a supply chain management 
framework in accordance with an embodiment of the present invention. A selection of at 
least one of a plurality of types of pricing schemes is received utilizing a graphical user 
interface in operation 19602. Utilizing the graphical user interface, a plurality of supplier 
20 sites are then displayed in operation 19604. At least one of a plurality of pricing fields 
are depicted adjacent the supplier sites based on the selection utilizing the graphical user 
interface in operation 19606. 

In one aspect of the present invention, the received pricing schemes may include at least 
25 one of supplier site pricing, volume pricing, and/or delivered pricing. In another aspect, 
the received pricing schemes may include all of supplier site pricing, volume pricing, and 
delivered pricing. In a further aspect, pricing information entered in the pricing fields 
may be utilized in a supply chain analysis. In an additional aspect, the selection may be 
received utilizing a network. In even another aspect, the selection may be received 
30 utilizing an icon of the graphical user interface. 
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Distribution Center Usage 

The Least Cost mechanism for estimating usage functions operates in the same manner as 
in the Bid System. It is comprised of two tabs, the DC/Rest tab is used for estimating 
restaurant growth by DC, and the Usage tab to estimate same store or item growth. The 
values from the first tab are used in the Usage tab to determine the projected usage. A 
more detailed explanation of the usage calculations is included in the section entitled 
Usage Estimator, below. 

Figure 197 is a depiction of a Projected Restaurant Growth screen 19700. The present 
invention provides the ability to estimate restaurant growth at two levels. First, by 
entering a percentage in the 'Total Rest. Growth Amount' 19702, the value will be copied 
and applied to all of the restaurant growth percentages at each DC. In the example shown 
in Figure 197, 5.00% was entered and propagated to each DC. The default value can also 
be overridden and data entered directly for each individual DC. Several of the fields are 
described below. 

• Total Rest. Growth Amount Any value entered will be applied uniformly across 
all DCs in the current analysis. 

• Restaurant Growth % The user can override the overall amount at each DC 
simply by entering an alternate estimate percentage. 

• Projected Avg. Rest. Count Based on the percentages entered, a projected 
restaurant count is calculated. The user also has the ability to enter values directly 
simply by entering an alternate value in the relevant cell. The projected restaurant 
will be carried over to the 'Usage' tab and will affect the DCs projected usage. 

Figure 198 illustrates a Projected Usage Estimation screen 19800. Several fields of the 
screen are described below. The projected usage for each DC is calculated based on 
projected restaurants served, data retrieved from Coordinator Link data and DC/Item 
Growth (same store growth). This projected usage number will be used by the solver for 
capacity information and also in output reports. 
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Item Growth % For each Item in the analysis, the user can enter an overall 
estimate for same store or item growth. As in the restaurant growth tab this value 
will be applied uniformly across all DCs. 

Usage Period Contract period for this analysis. Used to calculate the length of the 
contract in order to determine previous and projected usage. 
Previous Usage Previous Usage is the sales by cases reported to the 

Supply Chain Coordinator by each DC through the system Link. These sales are 
based on a time period that is in conjunction with the 'Usage Period'. This period 
is computed by taking the most recent date which the Supply Chain Coordinator 
has received data from all of the DCs and using it as the usage end date. The 
usage begin date is then computed by going backwards for the length of the 
proposed contract. For example, in the situation shown in Figure 198, the length 
of the contract is 1 year. If the most recent date that all DC data had been received 
was 3/1/01 then the previous usage period would be 4/1/00 to 3/1/01. This would 
provide a previous usage for the most recent twelve month period in the system. 
Projected Rest. Count The projected restaurant count is the number of restaurants 
that will be served by a DC for the period of the proposed contract. This number 
is copied from the DC/Rest tab. 

Coverage Factor % The coverage factor percentage is a number devised to 
correctly calculate the DCs projected usage. Coverage Factor is the percent of 
total restaurants that this DC has served this product to over the past year. For 
example, if a DC serves 200 restaurants in one month but only sells this item to 
100 of those restaurants then the coverage factor would be 50%. If the item was 
sold to all 200 restaurants then the coverage factor would be 100%. 
Avg. # RM Average number of restaurant months. This figure represents the 
average number of units sold to a restaurant for this item for any given month. 
This average is a 12 month rolling average calculated based on the data reported 
to the Supply Chain Coordinator by the DCs. 

DC/Item Growth At the DC level, the user can override the overall growth % 
by entering an alternate value for the relevant DC. 
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• Projected Usage 



The actual usage estimate for each Item / DC combination. 



Initially the projected usage will be calculated based on the following formula: 

(Projected Rest. Count * Avg. # RM * Coverage Factor % * DC/Item Growth * 
Number of Months in Contract) 

By editing the DC/Item Growth percentage (or overall Item Growth %), the projected 
usage can be manipulated to the desired level. The user can also directly edit the 
projected usage amount which will adjust the DC/Item Growth amount accordingly. 
Usage estimates calculated by the system are always in cases; hence if the user is entering 
pricing, volume or capacity constraints in any other unit, these values should be modified 
appropriately. 

Note that the previous usage amount is not used in the calculation of the projected usage 
amount. It is used as a guide only. La the example shown in Figure 198, no overall Item 
growth percentage was used, but chicken patty's were projected to grow by 4.00% at the 
Ameriserve in Omaha and 5.00% at the Ameriserve in Plymouth. 

Figure 199 is a flowchart of a process 19900 for projecting distribution center usage in a 
supply chain management framework in accordance with an embodiment of the present 
invention. A plurality of supply chain distributors are displayed utilizing a graphical user 
interface in operation 19902. The entry of a growth value is allowed in operation 19904 
utilizing the graphical user interface so that a projected parameter amount associated with 
the supply chain distributors can then be calculated based on the growth value in 
operation 19906. 

In one aspect of the present invention, the growth value may include a restaurant growth 
percentage. As a further aspect, the projected parameter amount may include a projected 
restaurant count. In another aspect, the growth value may include an item growth 
percentage. In a further aspect, the projected parameter amount may include a projected 
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item usage amount. In an additional aspect, the projected parameter includes an editable 
default value. 

Lane Restrictions 

In the Least Cost system, the ability is provided to override any solution that the solver 
determines and force certain lanes. The overrides can be established before the solver 
runs. 

It also a good habit to run a least cost version without any lane restrictions, so that an 
estimation of the relative cost of forcing or excluding lanes can be readily determined. 

Figure 200 illustrates an Excluding Lanes screen 20000 displayed upon selection of a 
Lane Restrict tab. In an earlier section, a description of excluding Suppliers and/or FOB 
points using the "Include" indicator was set forth. This is related to the Lane Restrict tab 
in that if an FOB point is excluded from an analysis version, the lanes are automatically 
excluded from that FOB point to each DC. In the example shown in Figure 200, 
Cavendish Farms was excluded; hence all lanes from that FOB are marked as excluded. 
The solver will never receive these lanes as potential choices when determining the least 
cost. It is also possible to exclude individual lanes from this tab. However, the user 
cannot include a lane if the FOB point has been excluded on the Capacity tab. 

It may also be necessary to ensure that certain lanes are forced regardless of whether the 
lane assignment will prevent the least cost from begin achieved. Figure 201 is a 
depiction of a Forcing Lanes window 20100. 

In this example, the "Required" option has been selected for the lane from J.R. Simplots 
Hermiston FOB to Post Albuquerque. The solver will allocate this lane prior to 
beginning its optimization calculations, hence ensuring that the remaining lane 
allocations will still minimize the total cost given the lane requirement. 
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In a multi-source problem, lanes can still be forced, although without adjusting the 
supporting input the FOB may also receive another DC. For example, if a user wishes a 
lane to be forced but not allow the relevant FOB to get another DC, the user can simply 
make the FOB'S maximum the DCs usage. 

If the product is being single sourced (1 FOB : IDC), a lane cannot be forced twice. For 
example if a user attempted to also force the Lamb FOB to Post Albuquerque, the 
message screen 20200 shown in Figure 202 would get the following message. 

The third Lane Restriction option is marked as Solver in the previous example, and 
simply means that the lane is available to the solver as a potential lane in the least cost 
solution. 

The Honor TL Rate boxes 20002 (Figure 200) are used to specify whether or not the 
Supplier will Honor Truckload (TL) rates for shipments that are not a Full Truckload. 
See the section below entitled Optimal Product Routing. 

Figure 203 is a flowchart of a process 20300 for restricting lanes in a supply chain 
management framework in accordance with an embodiment of the present invention. A 
plurality of distribution centers of a supply chain are displayed utilizing a graphical user 
interface in operation 20302. A lane restriction of each of the distribution centers is then 
designated utilizing the graphical user interface in operation 20304. The distribution 
centers are then conditionally involved in a supply chain analysis based on the 
designation in operation 20306. 

In one aspect of the present invention, it may be determined whether a supplier site has 
been excluded from the supply chain analysis so that the lane is involved in the supply 
chain analysis based on the determination. In another aspect, the lane may be allocated 
prior to the supply chain analysis upon the lane restriction of the distribution centers 
being designated as required. In a further aspect, the lane may be excluded during the 
supply chain analysis upon the lane restriction of the distribution centers being designated 
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as excluded. In event another aspect, the lane may be included during the supply chain 
analysis upon the lane restriction of the distribution centers being designated as to be 
solved. In an additional aspect, the designation may be received utilizing a network. 

5 Freight 

Freight quotes in the least cost system can either be Truckload or LTL. 

Figure 204 is an illustration of a Truckload Freight window 20400 displayed upon 
10 selection of a TL Freight tab. For each DC and FOB in the analysis, an input area 20402 
is provided for the Truckload Freight amount. Freight is assumed to be consistent across 
all items in the analysis. Prior to the solver run, the TL freight amount is converted to a 
case and/or unit freight rate using the Item/FOB tab cases per truckload, and the Item tab 
conversion factor. If the usage estimates entered suggest that an RDC rate may be 



1 5 applicable on any of the lanes, a lane from the FOB is automatically added to the 
relevant RDC to this tab. 



• Lane Distance: This amount is used in estimating freight competitiveness between 
the Supplier quote and internal estimates. The present invention automatically 



Note that omitting a rate for a lane has the same effect as excluding the lane. 

Figure 205 illustrates an LTL Freight page 20500. The Bid system automatically 
25 generates an LTL worksheet if it determines that certain lanes have the potential to order 
LTL. Based on the Usage estimates entered or calculated by the system and the gross 
weight or cube per case entered on the Item/FOB tab, an identification is made as to 
which lanes have the potential to order LTL and lanes on the LTL Freight Tab are 
automatically populated. 



20 



populates this column from the Supply System. 
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Q Figure 206 is a flowchart of a process 20600 for managing freight in a supply chain 

management framework in accordance with an embodiment of the present invention. A 
15 graphical user interface is utilized to display a plurality of distribution centers of a supply 
chain in operation 20602. Next, in operation 20604, a truckload freight value is received 
in an input field of the graphical user interface. The truckload freight value is converted 
in operation 20606 so that a supply chain analysis can then be performed using the 
converted truckload freight value in operation 20608. 



If; 



In the example shown in Figure 205, O.K. Foods has quoted LTL rates from their Fort 
Smith FOB to ProSource Atlanta and Burlington. All quotes are in $CWT (hundred 
weight), hence the Atlanta rate is $165 ($1.10 * 150) and the Burlington rate is $400 (The 
LTL minimum of $400 is not satisfied by the quoted rate of $180 (150 * 1.2)). The 
5 Optimal Product Routing (OPR) process will determine which rate to use based on its 
estimates of two week usage and compare the basket cost with both TL and RDC rates to 
determine the optimal routing. The entire OPR is discussed in detail in the section below 
entitled Optimal Product Routing. 

10 Preferably, as projected usage estimates are adjusted on the Usage tab, rows will be added 
and deleted to this tab when relevant. 



20 

In one aspect of the present invention, a suggested value may be displayed in an output 
field. In an additional aspect, the suggested value may be received from a supply chain 
manager utilizing a network. In another aspect, the truckload freight value may be 
converted to a case value. In a further aspect, the truckload freight value may be 
25 converted to a freight rate value. In an additional aspect, the truckload freight value may 
be received utilizing a network. 

Regional Restrictions 

30 Figure 207 depicts a restriction window 20700. The present invention provides the 
ability to force DCs in a region to be awarded the same FOB point. In the example 
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shown in Figure 207, a region is established to combine McCabe's DC in Portland and 
Restaurants North West DC in Alaska. By selecting the Force FOB option to "Yes", the 
solver will ensure that both DCs receive the same FOB point. 



5 Figure 208 is a flowchart of a process 20800 for imposing regional restrictions in a 
supply chain management framework in accordance with an embodiment of the present 
invention. A plurality of distribution centers of a supply chain are displayed utilizing a 
graphical user interface in operation 20802. A free on board (FOB) point associated with 
a region in which the distribution centers reside is identified in operation 20804. The 
10 distribution centers are then forced to use the FOB in response to a user action utilizing 
the graphical user interface in operation 20806. 

4 

3 In one aspect of the present invention, the user action includes the selection of an icon. 

$ In another aspect, the region may be user-defined. In a further aspect, a site role of each 

l l 15 of the distribution centers may also be displayed utilizing the graphical user interface. In 
| even another aspect, the graphical user interface may be displayed utilizing a network. In 

an additional aspect, the graphical user interface may be a browser-based interface. 

y Optimal Product Routing 

I 20 

a? 

I One of the major features in the least cost system is the Optimal Product Routing (OPR) 

feature. Because the present invention can factor Truckload, RDC and LTL lanes into the 
least cost analysis, the OPR engine will automatically determine the optimal routing prior 
to passing the data to the solver. OPR is automatically run prior to running the solver, 
25 but can also be run at any time using the Routing button 20900 on the toolbar. The 
Routing button is shown in Figure 209. 



Optimal Product Routing is the process of determining for each lane in an analysis, the 
lowest cost routing (Full Truckload [TL], LTL, RDC) for the Market Basket of Product. 
30 The capability is built directly into the Least Cost system. 
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OPR processing includes determining two-week usage as well as determining available 
routing information. 

Regarding two-week usage, the weight and cube of product shipped during a two-week 
period determines the possible routing types. Lanes with either a two-week weight of 
more than the amount specified in the analysis (typically 43,500 lbs.), and a two-week 
cube of more than 3,000 Cubic Feet will only travel TL. Those with less (non-truckload) 
may also travel LTL, and in the case of Dry product, may also travel RDC. Two-week 
weight usage is determined for all lanes included in the current version of the analysis. 



When determining available routing information, OPR finds the TL, LTL, and RDC 
information available for each lane and identifies incomplete or missing Freight 
information. It is important to gather freight quotes on all applicable routing types. For 
example, a Supplier may only quote an LTL or RDC freight for a non-truckload lane, yet 
1 5 due to the nature of the load it may cost less to ship the product with a standard truckload 
rate. 

OPR operates under the following assumptions: 

20 • Truckload There must be a TL freight amount. Even if available, LTL and 
RDC rates are not considered. 

♦ Non-Truckload Any TL or acceptable LTL routing freight amount will 
suffice, yet quotes for all routing types are strongly recommended. 

• Honor Truckload (TL) Rate For lanes that are not a Full Truckload, it is 

25 important to distinguish whether or not the Supplier will Honor Truckload (TL) 

rates. This is specified for each lane in the Lane Restrictions tab. 

Consider a lane which costs $1,000 to ship for a product which normally has 1,000 Cases 
per Truckload. Please refer to Table 29, below. If usage warranted a Full Truckload, the 
30 freight per case would be $1 (#1) 



291 



Now assume that the two-week usage for this lane is only 500 cases. The $1,000 
Supplier quote may imply either of the following: 

• Example #2 The $1 ,000 rate is the price to ship the lane, whether it is 5 or 500 
cases ($1,000 / 500 = $2 per case). 

• Example #3. Since the Supplier ships other products to the DC (e.g. other BKC 
products, products from, other concepts) he assumes that all of his trucks will 
ship full. The Supplier therefore Honors the TL rates, and even though the two- 
week usage is only 500 cases, charges a per case freight as if the usage warranted 
a Full Truckload ($1,000/ 1,000 = $1 per case). In this case, it may be useful to 
choose Honor TL rates on the Lane Restrictions tab of the Least Cost system. 



Table 29 



# 


Type 


Truck Frt 


cs/ 

Truck 


2-week 
Usage 


Freight 
/ Case 


Explanation 


1 


TL 


$1,000 


1,000 


1,000 


$ 1.00 


Frt/ CS per Truck 


2 


TLMIN 


$1,000 


1,000 


500 


$2.00 


Frt / Usage 


3 


HonorTL 


$1,000 


1,000 


500 


$ 1.00 


Frt / CS per Truck 



The status of Lane Freight information can be either Complete, Incomplete, or Optional: 

• Complete All relevant Freight information is available. OPR can 
continue. 

o Truckload shipments with Truckload rates 

o Non-Truckload, Dry shipments with TL, valid LTL, and RDC rates 
o Non-Truckload, Refrigerated shipments with TL and LTL rates 

• Incomplete Mandatory Freight information is missing. OPR cannot 
continue. 
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o Non-Truckload shipments with only an LTL Minimum rate provided (e.g. 

an LTL Minimum is provided, without specific weight class rates) 
o Non-Truckload shipments with LTL rates provided without an appropriate 

LTL Minimum 

5 o Non-Truckload shipments with LTL rates provided only for higher weight 

classes (e.g. A Supplier only provides a 10,001 - 20,000 lbs. rate for a lane 
with a 5,000 lb. Usage. This weight will never be satisfied.) 

• Optional Requested (not mandatory) Freight info is missing. OPR 

10 can continue. 

o Non-Truckload shipments with some, but not all of the applicable quotes 

(e.g. Dry shipments consider RDC rates, Refrigerated/Frozen do not) 
o Non-Truckload shipments with LTL rates provided for weight classes 
below the appropriate usage (e.g. A Supplier only provides a 10,001 - 
15 20,000 LBS. rate for a lane with a 22,000 lb. usage.) 

In order to ensure the lowest pricing, Logistics recommends requesting all relevant 
freight information from Suppliers. OPR will not continue if any lanes are Incomplete. 
OPR can, however, at user request, continue even though the status of certain lanes are 
20 Optional Realize however, that not requesting freight quotes on all applicable routing 
types may actually inadvertently place a Supplier at a competitive disadvantage. The 
Supply Chain Coordinator may award business based on Landed Cost, which includes 
freight. Performing a Least Cost analysis with missing freight information may yield 
inappropriate lane awards. 

25 

This information is available on the 'Solution Tab' of the Least Cost analysis under 
'Optimal Product Routing Reports'. More information on these reports can be found in 
the following section. 

30 The Least Cost system operates on a Market Basket concept for determining per case/unit 
and total shipment cost for all routings. It considers all Items shipping on a particular lane 
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in the relevant Unit (Case, Pound, Ounces) on which the analysis is based. For all routing 
types provided, OPR determines the Total Shipment amount for the entire usage 
specified, and the Unit Shipment amount required to ship a Unit of product. 

5 Shipment Cost is calculated as follows: 

• TL Product is shipped based on a Full Truckload freight quote. The Unit 
Shipment Cost is the Full Truckload cost / Units Per Truckload. 

• TLMIN For shipments smaller than a Full Truckload, it may prove more 
cost effective to ship the Product via the quoted TL rate. This routing is referred 

10 to as a Truckload Min, whereby the shipment has a TL quoted freight with a 

Minimum Order Quantity (MOQ) specified. The Unit Shipment Cost is the Full 
Truckload cost / Usage, except in the case of Honor TL Rate, where it is the Full 
Truckload Cost / Units Per Truckload. 

• LTL Product is shipped via an LTL carrier, that specializes in partial shipments. 
1 5 The shipment cost is based on a price per hundred weight, and possibly an overall 

minimum amount for the entire shipment. An LTL Minimum must be provided 
along with any LTL information. The Unit Shipment Cost is the Total LTL 
Shipment Cost / Usage. 

• RDC For Dry Products only (excluding Alaska and Hawaii RDC's), the Product 
20 is shipped via the appropriate Re-Distribution Center (Prosource or Chicago 

Consolidated RDC). Unit Shipment cost includes Inbound freight to the 
appropriate RDC, the RDC markup, and Outbound freight to the DC. When a 
product is shipped RDC, all shipment amounts assume Full Truckloads. 

25 Optimal Product Routing takes into account all of the available freight routing 

information and determines the lowest cost method of shipping the Market Basket of 
product for each lane. In the event of multiple routing types having identical shipment 
costs, OPR is decided in the following order of preference: TL, TLMIN, LTL, and RDC 
(Dry shipments only). 

30 
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Winning routing types are chosen on a lane-by-lane basis. When considering all lanes, 
however, this may not always be feasible. Certain lanes may be considered an RDC 
Override, and Optimal Product Routing will determine the best routing excluding the 
RDC rates for these lanes. Presented below are two examples of this: 

• Insufficient Usage - This occurs when the total usage is not sufficient to warrant 
a Full Truckload from the FOB to the respective RDC. For example, assume that 
OPR determined that FOB1 shall service DC1 and DC2 via the RDC, each with a 
respective usage weight of 10,000 lbs. The total usage from FOB1 to the RDC 
(20,000) is not sufficient to fill a truck. 

• Infeasible Coverage - This occurs when based on the winning load types for each 
lane a situation exists in which not all DCs can be serviced regardless of which 
FOB wins the RDC. This scenario is due to a rule that only one FOB can service 
an RDC for a particular product. For example, consider the following example in 
which two FOB's each bid on separate Prosource DCs. 



Table 30 



FOB 


LOAD TYPE 


DC1 


DC 2 


DC 3 


DC 4 


FOB 1 


RDC 


Yes 


Yes 






FOB 2 


RDC 






Yes 


Yes 



Note that the above is not feasible. There is no FOB that can service all of the DCs via 
the Prosource RDC. 

Table 31 



FOB 


LOAD TYPE 


DC1 


DC 2 


DC 3 


DC 4 


FOB 1 


RDC 


Yes 


Yes 






FOB 2 


RDC 






Yes 


Yes 


FOB 3 


LTL 


Yes 


Yes 
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In this example, however, it is feasible for FOB 2 to win the RDC, with DC 1 and DC 2 
being serviced by FOB 3. 

5 As with the Least Cost Analysis, OPR is calculated on a per Unit basis. As a last step, 
OPR populates a case freight table which is used to create Cost Matrices once an analysis 
is complete. All of this information is kept in the system for enhanced analysis by the 
Logistics department. 

10 Figure 210 illustrates a Report Selection window 21000. Several of the reports that can 
be selected are set forth below. 



• Freight Information Provided: At a Market Basket Level, contains Lane Freight 
Status, 2-week totals (Cases, Weight, Cube) and Freight Provided information for 



15 



each lane. 



• LTL Routing Grid By Lane: Displays all LTL information provided with shading 
to identify missing rates. 



20 



• Routing Results by Lane: At a Market Basket Level, contains Truckload and Unit 
Shipment amounts for each of the Load Types provided (TL, LTL, RDC), along 
with an indication of the Load Types chosen as the Optimal Product Routing 



winner. 
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• Routing Results by Lane, Item: At an actual Item level, contains Truckload and 
Unit Shipment amounts for the Load Types chosen for its lowest cost. This 
Shipment information is used to create Cost Matrices. 



30 



• Routing Results w/ RDC Breakout by Lane: A breakout of the RDC information 
provided in the Routing Results by Lane, detailing the Inbound, Markup, and 
Outbound freight amounts. 
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• Routing Results w/ RDC Breakout by Lane, Item: A breakout of the RDC 
information provided in the Routing Results by Lane, Item, detailing the Inbound, 
Markup, and Outbound freight amounts. 

5 

• TL Freight Variance Analysis: Compares Truckload Freight rates against Freight 
Per Mile benchmarks . 

• TL Freight Variance Analysis, by Case: Compares Truckload Freight rates against 
1 0 predetermined Freight Per Mile benchmarks at a Case Freight level. 

Figure 211 is a flowchart of a process 21100 for product routing in a supply chain 
management framework in accordance with an embodiment of the present invention. A 
plurality of lanes of a supply chain are identified in operation 21102. Next, a lowest cost 
1 5 routing scheme is determined for each of the lanes in operation 21 104. A supply chain 
analysis is then performed using the lowest cost routing scheme in operation 21106. 

In one aspect of the present invention, the lowest cost routing scheme may be selected 
from a group of schemes that includes less-than-truckload carriers (LTL), regional 

20 distribution centers (RDC), and full truckloads (FL). In another aspect, the lowest cost 
routing scheme may be determined automatically prior to performing the supply chain 
analysis. In a further aspect, a report reflecting the supply chain analysis may also be 
outputted. In an additional aspect, the lanes may be identified utilizing a network. In yet 
another aspect, results of the supply chain analysis may be outputted utilizing a browser- 

25 based interface. 

Solving and Reviewing the Solution 

Once all the required information has been entered, the problem can be solved from any 
30 of the tabs by selecting the Solve button 21200, shown in Figure 212. The processing 
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time will vary depending on the complexity of the problem and the quantity of the data 
that is being passed to the solver. 

It will pass through the following phases: 

• Solver Validation: Incomplete analysis data can be saved, but it is not valid to 
pass that information to the solver. For example, an analysis can be saved without 
filling in all the pricing, the solver cannot run until it is complete. 

• Feasibility Check: A preliminary check is ran to ensure that the problem 
definition attempted to be solved is feasible. Infeasible scenarios would include, 
say, a lane requirement with no relevant freight quote, or Supplier minimums 
greater then the sum of the Supplier's FOB maximums. A list of exemplary 
checks are as follows. 

o Sum of FOB max < Supplier min 

o Sum of FOB min > Supplier max 

o DC has Usage but no Freight (e.g. no Freight quote or all Lanes Excluded) 

o Total Usage > Total Supplier max 

o Total Usage > Total FOB max 

o Required Lanes, No Freight 

o Required Lanes, insufficient Supplier capacity 

o Required Lanes, insufficient FOB capacity 

o Valid Lanes, insufficient Usage for Supplier min capacity 

o Valid Lanes, insufficient Usage for FOB min capacity 

o DC Usage > Any FOB max 

o Lane without facility 

• Optimal Product Routing: First, a determination is made as to whether there is 
a need to run OPR or not, and if there is the process will run. 

• Weighted Delivered: The weighted average delivered cost for the basket of 
products for each lane is calculated. If applicable the optimal freight is included 
from the OPR process. 
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• Check Solver Availability: Whether licensing allows one or more concurrent 
users 

• Run the Solver: Invoke the solver engine 

• Insert Results: Grab the results from the solver and update the Supply 
System. 

Figure 213 illustrates the Report Selection window 21300 which allows selection of the 
report type. The Report Type menu d7402 lists associated reports. 

The report generator for the least cost system operates in the same manner as the report 
generator in the Utilities' menu of the Supply System. 

The Least Cost system has several reports available to analyze and view the solution 
generated by the solver. These reports fall under the following categories. 

• Awarded Volume: Awarded Volume reports are used to show each FOB/DC 
combination and it's awarded volumes. These reports can be used for specific 
items or the market basket. Figure 214 illustrates a Report Name drop down list 
21400 of related reports. 

o Awarded Volume by Item - Detail Solver solution with a 

breakout of each lane awarded, the Invoice FOB (and relevant contract 

FOB), freight and estimated sales, 
o Awarded Volume by Item - Freight Solver solution with a 

breakout of the freight costs on each lane, as well as the period and 

annualized freight totals, 
o Awarded Volume by Item - Summary Solver solution with 

Supplier and FOB summary totals only, 
o Competing DC Freight Analysis by Item A freight analysis between a 

series of pre-defined "competitive" DCs based on the latest finalized Cost 

Matrix and the selected version. 



299 



o Lane Assignment Matrix A lane assignment grid to quickly review the 
solver solution, FOB capacity constraints and the Contract FOB used. 

o Lane Weighted Average Delivered Cost A complete lane grid 

detailing the delivered costs on each lane. For FOBs with volume pricing, 
the delivered costs are based on the awarded volume to each FOB point. 

Comparison Reports: The comparison reports enable a user to compare different 
versions of an analysis against each other or against the latest finalized cost 
matrix by item. Figure 215 illustrates a Report Name drop down list 21500 listing 
related reports. 

o Assigned Volume Percentages A FOB comparison of awards and 

award percentages of overall volume, 
o Invoice FOB Detail Comparison A DC comparison of invoice price, 

freight, delivered costs and routing. It also shows weighted average and 

summary totals. 

o Invoice FOB Savings Comparison An overall comparison of invoice 
price, weighted average freight and delivered costs and summary totals. 
When compared with a Cost Matrix it will calculate the savings estimate 
between the matrix and the versions selected. 

Cost Matrix Preview: The cost matrix preview report enables the user to preview 
the cost matrix that would be created from the selected analysis version, before it 
is actually created in the Supply System. Running this report will show the user 
all of the DC/FOB combinations and the costs associated with them. The user can 
also preview the cost matrices from the "Cost" toolbar option. 
Optimal Product Routing: OPR reports are used to view the results of the OPR 
processing. Here the user can check information entered and also the information 
that OPR has generated. Reports include an OPR by item and OPR by lane report. 
For a full explanation of the OPR reports, see the earlier section entitled Optimal 
Product Routing. 
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• Tab Reports: The tab reports will generate reports designed for specific tabs. 
Here the user can also generate a report for each tab within the least cost analysis. 
Use this option to view a report of all information for an analysis. 

5 Note that data on individual tabs can be printed using the print option on the toolbar for 
that specific tab. 

The present invention also allows a user to retrieve Comparison Reports. The example 
below will retrieve the 'Invoice FOB Comparison Report (no conversion)'. Note that the 
10 term "conversion" refers to whether the report should show the price information in the 
analysis units (ex: pounds, pours) or convert the price information to cases. If the analysis 
^ was performed in cases, then with and without conversion will be the same. 

% First, the 'Comparison Reports' report type is selected from the Report Type drop down 

1 1 5 list. After selecting the Comparison Reports report type the Report Name should appear 
3 as shown in the Report Selection window 21000 of Figure 216. Next, the report is 

selected from the Report name drop down. In this example, 'Invoice FOB Detail 

3 Comparison (no conversion)' is selected from the report name drop down list 21700. See 
jj Figure 217. 

I 20 

4 Upon selection of the report name, the appropriate parameter entry fields 21800, shown 
in Figure 218, are enabled in the lower portion of the screen. As shown in Figure 218, 
this report allows selection of an item, multiple versions of the current analysis (using 
CTRL+Click), and whether to include the latest finalized cost matrix for the current item 

25 in the comparison. 

In the example above, for HASH BROWNS, the solution for two versions and the latest 
finalized cost matrix will be compared. 

30 After the correct parameters have been chosen, the report can be prepared for output to 
the user. Clicking on the 'Retrieve' button 21900 on the toolbar will retrieve this report 
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and open a window so the user can view or print the data. A Retrieve button is shown in 
Figure 219. 

The process is the same for any report a user wishes to view. The only difference is the 
5 parameters that can be selected. 

Figure 220 is a flowchart of a process 22000 for comparison reporting in a supply chain 
management framework in accordance with an embodiment of the present invention. A 
plurality of supply chain analyses are selected in operation 22002. Results of the selected 
10 supply chain analyses are located in operation 22004. The results of the supply chain 
analyses are then compared in operation 22006 and a report on the comparison is 
generated in operation 22008. 



In one aspect, each of the supply chain analyses may include a separate version of a 
1 : 1 ] 15 single supply chain analysis. In another aspect, the results may include cost information. 

In a further aspect, the supply chain analyses may be selected utilizing a network. In 
such an aspect, the supply chain analyses may be selected utilizing TCP/IP protocol. 
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Creating the Cost Matrices 

Since the solver input, routing and solutions are already stored in the system, to generate 
cost matrices, the user simply has to identify the version from which he or she wishes to 
create the matrices and select the Cost button 22100 on the toolbar. Figure 221 illustrates 
a Cost button. 

Figure 222 is a depiction of a Cost Matrix Creation window 22200 displayed upon 
selection of the Cost button. The present invention provides two options at this point: 
the matrices can be created, or a preview of them can be generated and output before 
creation. 
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Preview button: allows the user to preview the exact information that will 

be inserted if a decision is made to create the matrices. 

Create Cost button: creates all Cost matrices based on the solution for the 



current version. 
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If the system detects any matrices in the system which cause a conflict, a list of those 
matrices is output. Preferably, the user can only overwrite an existing matrix if the dates 
are the same as in the analysis and the existing matrix has not been finalized. The matrix 
that is created by the least cost system can be edited as normal and is created un- 



The present invention automatically generates both inbound and outbound RDC lanes to 
ProSource and Chicago Consolidated when the user inputs a command to create or 
preview the cost matrices. 



In a preferred embodiment, the solver is designed to restrict each RDC to have only one 
FOB point. Hence the cost matrix will generate one inbound lane to either RDC and 
automatically populate the outbound lanes with the relevant Contract and Invoice FOB 
based on the landed cost to the RDC plus markup and the relevant outbound freight. 

20 

If volume pricing is used, the sum of the awards across all RDC lanes that the solver 
selects can be used to determine the relevant price. 

Usage Estimator 

25 

The Bid Proposal and Least Cost systems both have a Usage Estimator module which 
provides a sophisticated mechanism for projecting product case usage by DC for a 
particular period. The Usage Estimator takes into account for each DC the following: 

30 • Projected Average Restaurant Count 

• Previous Usage (Average Units sold per Restaurant ) 



10 



finalized. 
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• Product Growth 

• Coverage Factor 

The Usage Estimator is made up of two pieces, DC/Restaurant Information (DC/Rest) 
5 and Usage information (Usage). In order to determine the projected product case usage, 
the system must first calculate the Projected Average Restaurant Count, so the 
DC/Restaurant portion of the Usage Estimator will be discussed first. 

Regarding the DC/Restaurant Information, a Current Restaurant Count is provided 
10 monthly by the DCs in the form of Distributor Reported Landed Cost. This information, 
verified by Finance for Patronage Dividend purposes, provides an accurate monthly 
snapshot of Restaurant counts by DC. The Usage Estimator uses the most current month 
of information available for each DC. 

1 5 Also provided with the DC/Restaurant Information is a Restaurant Growth Percent 
(Average) report which specifies the overall average increase/decrease in restaurant 
coverage that each DC will experience for the length of the Contract Period in question. 
Consider the following example: A DC currently services 100 Restaurants. At the end of 
the 1-year pricing, the DC will be servicing 1 10 Restaurants. The Projected Average 

20 Restaurant Count would be (1 10-100) / 2 - 105. The Restaurant Growth Percent in this 
case is (105-100) / 100, or 5%. 

The Usage Information provided includes Previous Case Usage. This includes the actual 
number of cases sold by this DC during the previous period. Each month, the Supply 

25 Chain Coordinator receives Product Sales statistics from each of the DCs. This 

information contains case sales of each Distributor's Item, along with the number of 
Restaurants that product was sold to during the month. The Previous Case Usage number 
itself is not used directly to calculate Projected Usage, as it would not allow manipulation 
of DC Served information. This information is available under Sales/Inv - Distributor 

30 Sales from within the Supply System. 
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Previous Period usage information is determined by the latest information available from 
the DCs. For example, assume that on December 1, a Bid for a Contract Period from 
January to June will be completed. At this point, the system would have probably only 
received complete DC information through October. Since the Contract Period is 6 
5 months, the Previous Case Usage would report usage for the latest 6-month period of DC 
Sales information (May thru October). This is considered the Previous Period. 

The Average Units sold per Restaurant Month includes the average number of cases per 
month of product sold by a DC to the Restaurants it services, for those restaurants that 
10 receive product during the month. Remember, not all Restaurants will receive each 

product during each month. This figure, unlike the Previous Period information, is based 
on the latest complete 12-month rolling average of DC Sales information. 

A Projected Average Restaurant Count is calculated by multiplying the Current Restaurant 

1 ! 1 5 Count by the Average Restaurant Growth Percent. This number is manipulated on the 

i 

a DC/Rest tab. 
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A Product Growth Percent can also be calculated. The Usage Estimator allows the user to 
effect Projected Usage via a Product Growth Percent. For example, BKC may estimate a 
20 5% jump in sales for a particular product during the length of the Contract Period due to 
national promotions, product mix changes, etc. 

The Usage Estimator takes into account the fact that a particular Item is not necessarily 
sold to all Restaurants that a DC services. Some items are purchaser's options, others 

25 such as sausage patties, come in different sizes. Even an Item such as the Whopper will 
not be sold to 100% of a DCs Restaurants each month due to mid-month store openings 
and closings. Coverage Factor is calculated by dividing the number of Restaurants a 
Product was sold to by Restaurant Count during that Period. For example, if a DC 
Services 100 Restaurants during a month and sold SAUSAGE 1.5 PATTIES to 50 of 

30 them, this Item would have a Coverage Factor of 50/100 or 50%. Because of the 
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difficulty of collecting each Invoice a Restaurant receives, the DCs provide a monthly 
report of the number of cases sold and the number of Restaurants the product was sold to. 

To illustrate, consider the following: 

Table 32 



Restaurants Served 



B 



Current Rest Proj. Avg 
Growth 
Rest (Average) Rest 
Count Count 

(A*B) 



100 



10% 



110 



Product Sales Per 




Covera 


Restaurant 






ge 


D E F 


G 


H 


I 


Avg Produc Proj Avg 


Number 


Proj. 


Covera 


Units t 




Units 


ge 


Per Growt Units/Mo 


of 


Per Rest 


Factor 


Month h nth 


Months 










(F*G) 




150 10% 165 


12 


1,980 


95% 




206,910 



Remember, Projected Usage is comprised of the following: 

• Projected Average Restaurant Count 

• Proj ected Average Units 

(Previous Usage [Average Units sold per Restaurant] * Product Growth) 

• Coverage Factor 

Realize that zero growth will still give a higher Projected Usage. It's important to 
remember that the Previous usage is based on a changing Restaurant base. For example, 
assume that a DC last year started with 100 Restaurants and ended up with 1 10, and that 
the Average Units Per Month was 10. This DC would have sold an average of 1050 units 
per month (the Average Restaurant Count is 105). Notice that even if no Restaurant or 
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Sales growth occurs the next year, the Projected Usage will be higher than 1050, because 
of the fact that there are 1 10 Restaurants at the start (110*10-1 100). 

The process of estimating usage is user-friendly, providing DC level information, with 
user-input adjustments for Restaurant and Product Growth. 

Landed Cost / Restaurant Count information includes: 

• Case Sales by Distributor / DC 

• Landed Cost by Distributor / DC 

• Restaurant Counts by Distributor / DC 

• Product Counts by Distributor / DC 

• Average Landed Cost Per Case 

• Average Cases Per Restaurant 

• Average Landed Cost Per Restaurant 

• Sales reported for Items not in the Product File 

• Inventory reported for Items not in the Product File 

• Percentage Growth by DC - Product Sales 

• Percentage Growth by DC - Landed Cost 

• Percentage Growth by DC - Restaurant Base 

• Percentage Growth - Product Count 

• Percentage Growth by DC - Product Count 

Each Distributor references a system Item by it's own Distributor Item and Distributor 
Item Description. For example, a Whopper can be referred to as "BEEF-WHOPPER 4.0 
OZ", while another company calls it "WHOPPER", and a third company calls it 
"WHOPPER CS/144EA". Cross-referencing, or matching system items with each of the 
Distributors', is what allows a user to view inventory or sales for the Whopper without 
knowing the Distributor's naming conventions. 
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In some cases, a Distributor may have more than one Item (SKU) for a particular system 
Item. A slight packaging change may cause the Distributor to create 2 SKU's for what 
could otherwise be considered one system Item. 

5 For example, a DC that services 100 Restaurants changes SKU's mid-month and reports 
selling 1000 cases of the first SKU to half of its Restaurants, and 1000 cases of the 
second SKU to the other half. Average Units sold per Restaurant Month in this case, 
would be the number of Items sold (2000) divided by the Restaurant Count (100), or 20. 

10 A Distributor may not always change an SKU. They may consider CUP-PROMO a catch 
all even though there is a separate Item for each CUP promotion. 

S ; .3 

Mi J-?" 

time the Usage Estimator is used, the following should be verified: 
Appropriate DCs are accounted for in Previous Case Usage 
DC Items appear to be properly Cross-Referenced 

Reasonableness of DC Sales Monthly Detail information for this Item (Sales/Inv - 
Direct to Restaurant) 

Previous Case Usage and Average Units sold per Restaurant are reasonable and 
consistent 

DC Sales information coincides with Supplier Sales for the Item (taking timing 
and DC inventory into account). 

Beef Formula Pricing System Example 

25 The Formula Pricing System of the present invention allows quick and easy calculation 
of the weekly meat block cost for all suppliers. 

A new Formula Pricing can be created in either of two ways. The first one is to build a 
Formula Pricing from scratch. The second method uses the "New Using Previous" 
30 feature, which will create an entire copy of a previous Formula Pricing and allow a user 
to make the necessary modifications. 
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Figure 223 illustrates the Formula Pricing submenu 22300 of the Supply drop down 
menu. To create a new Formula Pricing, select Edit / View to bpen an existing Formula 
Pricing or create a new one. After selecting the Edit / View menu option, the standard 
query screen is displayed. Select New. 

To use the New Using Previous feature, select New (Using Previous) from the Formula 
Pricing submenu to copy an existing Formula Pricing into a new one. A complete copy 
of a previous Formula Pricing can be made by selecting this option. 

Figure 224 illustrates a Formula Pricing window 22400. As shown in Figure 224, the 
Formula Pricing window is made up of several different tabs. The labels identify these 
tabs across the top of the window. Examples of these tabs are Tricing', 'Formulas' and 
'Block Cost'. 

The first tab visible on the Formula Pricing window when it is opened is the 'General 
Info' tab, which shows pricing description, item, date ranges and Adjustment amount. 
This tab is where general information for this Formula Pricing is entered. The fields of 
the General Info page include: 

• Pricing ID: Unique identifier for this Pricing. Generated by the Supply System. Non 
editable. 

• Description: Unique name for this Pricing. It should representative of the type of 
Formula Pricing being completed, and will be the primary method of identifying and 
retrieving the Pricing later. 

• Item: Item whose Price is being calculated. After the Pricing information is saved this 
field is grayed out, becoming non-editable. 

• Raw Material Pricing Date: The Coordinator/Supply System calculates this date but it 
may be changed. The system will pick up the last Monday used for the chosen item 
and calculate the next Monday. After entering this date or accepting the system 
generated one, the Formula Pricing date range is calculated as follows: The To Date is 
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calculated subtracting 3 days from Raw Material Pricing Date (Monday) which will 
give a Friday. Then 1 1 days are subtracted from this date to calculate the From date 
(Friday). This date calculation may be changed by the IS Development staff. 

• Cost Matrix Begin Date (and End Date): Cost Matrix Date period associated to this 
item Formula Pricing. 

• FOB Adjustment Amount: Upcharge or downcharge applied to formula calculation. 

Figure 225 depicts the page 22500 displayed upon selecting the Pricing Tab. After 
entering all of the information on 'General Info' tab, the user will be now be able to move 
to the next tab Tricing'. This tab is used to enter the prices of the raw materials for the 
Formula Pricing period. 

The Date column includes the period dates excluding weekends. These dates can be 
modified. If the date exist in a previous pricing, the message window 22600 shown in 
Figure 226 will pop up. If the user answers yes, the prices for that date will be inserted 
into the current Formula Pricing. 

If there are more than one pricing with the same date, the message window 22700 shown 
in Figure 227 will appear. If the user answers yes, a selection window 22800, depicted in 
Figure 228, will appear to allow selection of the pricing data that the user wants to copy 
over the current pricing. 

Some of the raw materials price is calculated based on other materials. The following is 
an illustrative list of these materials with their formulas. 

Fresh Domestic 73% Trim: 

(Fresh Domestic 75% Trim / 75) x 73 

Fresh Domestic 80% Lean: 

(Fresh Domestic 85% Trim / 85) x 80 
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Fresh Domestic 90% Lean: 

(Fresh Domestic 90% Lean Blue + Fresh Domestic 90% Lean Yellow) / 2 

Lean Finely Textured Beef: 

(Fresh Domestic 90% Lean x 0.80 (or 0.82)) 

Figure 229 is an illustration of the page 22900 displayed upon selection of the Freight 
Tab. The Freight tab shows the freight amount that will be added to raw material per 
Supplier FOB. Preferably, the Freight tab is display only. 

Figure 230 is a depiction of the page 23000 displayed upon selection of the Formulas 
Tab. This tab is also display only and it will show the different formula values for each 
supplier. The columns of the Formulas Tab page include: 

• Formula: Generic name of the formula, which include an acronym for the 
supplier's name and a number. 

• Pet.: Percentage of raw material used in the formula. 

• Cost: Cost of raw material based on percentage (Price + Freight). 

• Total: Sum of all the costs in formula. 

Formula Descriptions: 

The following Table describes illustrative formulas. The freight amount, if any, is added 
to each raw material average market quote. 



Table 33 



Company A Food Service: 



Raw Material 



Percentage 



Fresh Domestic 50% Trim 



31.200% 



Fresh Domestic 90% Lean 



18.800% 



Imported Australian 90% Lean 



40.000% 
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Lean Finely Textured Beef 



10.000% 



Figure 231 illustrates the page 23100 displayed upon selection of the Block Cost Tab. 
The Block Cost tab creates the FOB price based on the previous tab calculations and the 
yield and margin. The columns displayed include: 

• Formula: Formula short name (supplier). 

• Raw Material Cost: Total amount from previous tab. 

• Yield: Processing yield (inverse shrinkage). For example on AFS-1 there is a 0.01 
loss of material. 

• Block Cost: Calculated field. Raw Material Cost / Yield. 

• Margin: Supplier's markup. 

• FOB Price: Sum of Block Cost and Margin. 

• Include?: Specifies if the formula price will be used. 

Figure 232 is a depiction of the page 23200 displayed upon selection of the Adjustments 
Tab. The final FOB Price may be modified using the Adjustments tab. The toolbar icons 
23300, 23302 shown in Figure 233 are used to insert or delete adjustments. 

After the Formula Pricing is completed the user can print the Raw Material Letter which 
describes the prices of the raw materials for the different suppliers of the current Formula 
Pricing. To retrieve the Raw Material Letter, the RM Letter icon 23400 is selected. See 
Figure 234. 

Figure 235 illustrates the Formula Maintenance window 23500 that is used to modify or 
add new formulas. To open the Formula Maintenance window, the Formula Maintenance 
menu item 23600 is selected from the Formula Pricing submenu, as shown in Figure 236. 

The top portion of this window shows the formula's main information, including: 
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• Formula ID: Unique identifier for each formula. Generated by the Supply System. 
Non editable. 

• Facility: FOB for each formula. 

• Description: Formula's unique name. 

• Short Name: Unique code for each formula. Used as a label in Formula Pricing main 
window. 

• The bottom portion of the window displays detailed information of the selected 
formula from the top. 

• Material Type: Raw materials used in the selected formula. 

• Begin Date: Starting date of formula percentage. 

• Percentage: Amount of raw material used to create a finished item. The sum of the 
percentage must total 1 00. 

In Summary 

The new technological infrastructure and its associated electronic reporting and feedback 
systems equips retailer management with accurate, timely, and previously unavailable 
information from the Supply Chain on sales, marketing and other performance indicators 
allow Supply Chain management to fully engage in managing supply and distribution 
processes and channels toward identified and agreed strategic objectives provide 
franchisees and retailers with the Supply Chain information they need to operate 
efficiently and make effective management decisions minimally impacts the resources of 
Supply Chain management 

With Supply Chain management assuming full responsibility for managing the 
fundamentals of the Supply Chain system, Supply Chain participants are strategically 
positioned to focus on the six business priorities that have been identified: operational 
excellence, boosting sales growth, focusing resources, discovering the essence of the 
Brand, image transformation and revitalizing franchisee relations. 
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While various embodiments have been described above, it should be understood that they 
have been presented by way of example only, and not limitation. Thus, the breadth and 
scope of a preferred embodiment should not be limited by any of the above described 
exemplary embodiments, but should be defined only in accordance with the following 
claims and their equivalents. 
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